Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Juliaup launcher Crash Report #845

Open
marcom opened this issue Feb 20, 2024 · 0 comments
Open

Juliaup launcher Crash Report #845

marcom opened this issue Feb 20, 2024 · 0 comments

Comments

@marcom
Copy link

marcom commented Feb 20, 2024

I previously added a comment to #732 (comment), but I opened a new issue as the error message is different.

Running juliaup or julialauncher results in a crash. I think it is due to file locking not working on the filesystem (NFSv3 at the university, NLM seems to have stopped working). This is on Linux. I think something on our network config was changed by the admins, resulting in NLM not working anymore, which results in file locking failing on the NFS mounted dirs (where I have installed julia/juliaup).

A possible workaround would be to allow an environment var to change the lock file location as described in #844 .

"name" = "Juliaup launcher"
"operating_system" = "Linux [64-bit]"
"crate_version" = "1.14.5"
"explanation" = """
Panic occurred in file 'src/config_file.rs' at line 166
"""
"cause" = "called `Result::unwrap()` on an `Err` value: Os { code: 37, kind: Uncategorized, message: \"No locks available\" }"
"method" = "Panic"
"backtrace" = """

   0: 0x5565c6ac5d60 - juliaup::config_file::load_config_db::h7e9d39e2d7499445
   1: 0x5565c6a33372 - julialauncher::run_app::hb135a07abdb38f63
   2: 0x5565c6a3ae9b - julialauncher::main::h865068469b405a8f
   3: 0x5565c6a2a8d3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hbcdfd77d36b49889
   4: 0x5565c6a2b261 - std::rt::lang_start::h8731c304bc39dbb6
   5: 0x7fcd3a0281b0 - __libc_start_call_main
   6: 0x7fcd3a028279 - __libc_start_main@GLIBC_2.2.5
   7: 0x5565c6a2a699 - _start
   8:        0x0 - <unresolved>"""

I used this little python program to confirm that file locking doesn't work on the NFS mounted home dir:

#!/usr/bin/env python3

import argparse
import fcntl
import sys
import time

def test_lock(file_path):
    with open(file_path, 'w') as f:
        print(f"Attempting to lock the file: {file_path}")
        try:
            fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
            print("Lock acquired. Holding for 5 seconds...")
            time.sleep(5)
            print("Releasing lock.")
            fcntl.flock(f, fcntl.LOCK_UN)
        except IOError as e:
            print(f"Error: Unable to acquire the lock on {file_path}. Error: {e}")
            return 1
    return 0

def main(argv):
    parser = argparse.ArgumentParser(description='Test file locking')
    parser.add_argument('file_path', type=str, help='Path to the file for locking test.')
    args = parser.parse_args(argv[1:])  # skip the script name in argv[0]

    return test_lock(args.file_path)

if __name__ == '__main__':
    sys.exit(main(sys.argv))

It works on /tmp:

$ ~/bin/locktest.py /tmp/foo
Attempting to lock the file: /tmp/foo
Lock acquired. Holding for 5 seconds...
Releasing lock.

But fails on the home dir (mounted via NFS):

$ ~/bin/locktest.py ~/foo
Attempting to lock the file: ~/foo
Error: Unable to acquire the lock on ~/foo. Error: [Errno 37] No locks available
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant