You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: