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

pid-file behavior #670

Closed
meejah opened this issue Sep 10, 2022 · 1 comment · Fixed by #671
Closed

pid-file behavior #670

meejah opened this issue Sep 10, 2022 · 1 comment · Fixed by #671

Comments

@meejah
Copy link
Collaborator

meejah commented Sep 10, 2022

Currently, magic-folder produces a "pid-file".

When magic-folder run starts, this pid-file is checked.

  • If there is no file, startup proceeds.

  • If there is a file:

    • the PID is read from it
    • if no such process exists, startup proceeds
    • if the process exists:
      • ..and the command-line appears to be a magic-folder, that one is killed and startup proceeds
      • otherwise an error is produced and the process exits

We may wish to change the latter behavior. Another way to handle this would be to assume that the PID file is stale and some other process happened to get that PID (so, proceed with startup).

A port of BSD pid-file handling (https://linux.die.net/man/3/pidfile) additionally uses locking (we can't on Windows, but otherwise could do this too) and suggests the correct behavior is to exit if there is any process running with the PID in the pid-file.

The purpose of having a pid-file in the first place is to avoid running a second instance of magic-folder upon the same configuration (which could corrupt it or lead to other undefined behavior). We could simplify our behavior to the above-linked BSD-like behavior (leaving it up to the caller to decide if the pid-file is stale or not). That is, don't do the optional kill and always exit.

This would mean that any "parent" program such as Gridsync would be responsible for deciding "is this a magic-folder instance or not" .. that is, the "if the process exists" logic above. If a human is using the command-line to run the program (or some manager like systemd) then they must decide if it is stale or not.

@meejah
Copy link
Collaborator Author

meejah commented Sep 10, 2022

The only circumstance when a "stale" PID file should sit around is if magic-folder crashes or is killed with SIGKILL or so (i.e. doesn't have a chance to run any exit handling).

In some Gridsync code we recently decided that the PID-file has both the process-id and the process start-time -- the latter to help decide "is this stale". The thinking being that the "name" of the process can be changed (and the command-line?) by the running program, but the (pid, start-time) tuple is extremely likely to be unique even if the PID got recycled (because then the start-time will be newer).

So, that's another possibility here -- change our logic to look at the process start-time when deciding "is this pid-file stale?" -- and leave that logic "inside" magic-folder.

@meejah meejah mentioned this issue Sep 14, 2022
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

Successfully merging a pull request may close this issue.

1 participant