Write daemon's PID to file on startup

[jiripospisil]

Helllo @laino! I use systemd to launch final-pm on system boot and while it's working fine (systemd is able to "guess" the just launched daemon's PID), it would be great if final-pm wrote the daemon's PID into a file (~/.final-pm/daemon.pid maybe?) once it's up. It would make the setup more robust. What do you think?

[laino]

While a PID file might be useful, the best way to run the final-pm daemon via systemd would be to directly
launch the daemon executable.

The executable bin/daemon just takes an URI to bind to (unix:// or tcp://) for its one argument. Example: node node_modules/.bin/final-pm-daemon unix:///tmp/test-sock.sock

The daemon logs to stdout and stderr, meaning you can comfortably redirect logging from the parent process to wherever you want those to go. The final-pm "launcher" just sets stdout/stderr to
open file descriptors of the configured log file. Systemd on the other hand will send stdout/stderr to journald by default.

The daemon's signal handling might need to be re-thought for that though, since
SIGINT initiates a fast shutdown (where the daemon SIGKILLs all processes and
loggers receive their configured kill-signal). Maybe there should be a mode
where the daemon cleanly stops everything before exiting on SIGINT.
This might mean your system will take hours to shutdown depending on how your applications
stop though.

I'll have to make a one-line change so the daemon doesn't expect an open IPC channel on launch, but once I've done so I'll provide an example systemd configuration and probably provide a built-in logger
for logging to journald as well.

[laino]

The one-line change I talked about is already in the repo if you want to try it out. There's no release (yet) though - not until some more thought went into this.

Changing anything about this later on might break existing setups.

[jiripospisil]

While a PID file might be useful, the best way to run the final-pm daemon via systemd would be to directly launch the daemon executable.

Having final-pm run in the foreground is certainly an alternative. Maybe It could be even exposed in the CLI interface via -f/--foreground/--no-daemon.

The daemon's signal handling might need to be re-thought for that though, since
SIGINT initiates a fast shutdown (where the daemon SIGKILLs all processes and
loggers receive their configured kill-signal). Maybe there should be a mode
where the daemon cleanly stops everything before exiting on SIGINT.

Either that or advise users to customize ExecStop to do something like ... --wait --kill stop all along with properly configured TimeoutStopSec and kill mode.

This might mean your system will take hours to shutdown depending on how your applications
stop though.

This is already configurable via stop-timeout, isn't it? The clean stop would just respect it as usual.

I'll provide an example systemd configuration and probably provide a built-in logger
for logging to journald as well

👍

[laino]

Having final-pm run in the foreground is certainly an alternative. Maybe It could be even exposed in the CLI interface via -f/--foreground/--no-daemon.

This would mean having all the CLI code loaded into the daemon process though. The CLI code isn't as rigorously tested as the daemon (as you already discovered yourself) and it also pulls a ton of extra dependencies. I don't really want all that in a lean daemon...

This is already configurable via stop-timeout, isn't it? The clean stop would just respect it as usual.

Yes.

Just thinking of my own use-case here where a clean stop of a process might take as long as a few days, since it waits until all clients have disconnected. That is usually what I want when I'm just restarting my application within final-pm to get to a new version. But it's not what I'd want to happen when I'm restarting the whole server.

Either that or advise users to customize ExecStop to do something like ... --wait --kill stop all along with properly configured TimeoutStopSec and kill mode.

An added bonus of this approach is that it makes the shutdown behavior of the daemon essentially configurable via your systemd unit file, solving the issue I just raised.