@aquette @clepple @peterhoeg : does this seem reasonable to you?

To me seems ok - reduces dependency on PID files and reduces forking ;)

@jimklimov if we are going to change the forking behavior, I would prefer that all of the daemons have similar options added at the same time. I also haven't looked to see how this works on a live system when upsmon forks off the unprivileged child. Hopefully, systemd only complains about the combination of fork() and exit().

This has been pretty low on my priority list, though - I have been running components of NUT in the foreground for the last several years under OS X launchd with -D, and the performance hit is negligible.

We've had some talk about this at https://github.com/NixOS as well, because there are pros and cons.

Systemd will consider a Type=simple running pretty much as soon as it has been executed.

Historically, for services that did the pidfile/double-forking dance, they would typically only fork when all the setup had been completed which is when systemd will say "OK, this is running". Systemd will then only start executing dependant services when the parent is actually up.

In the Type=simple case, there could be a brief moment between when systemd thinks all is OK but the daemon is still initializing. That may or may not be an issue for other daemons that depend on it.

If that brief gap is not an issue, I'd say go for it and run in the foreground but that is a call only you can make.

The other option is to make use of sd_notify where the daemon runs in the foreground but communicates with systemd to signal all is done. Then it runs in the foreground without any ugly double-forking. Additionally you would be able to very easily implement a heartbeat on top of this so in case of problems with nut, systemd would know how to restart it, which I personally think is an awesome feature for something as infrastructure critical as nut.

Reference:

• https://www.freedesktop.org/software/systemd/man/sd_notify.html

@peterhoeg I probably should have been more specific. Agreed that this pull request adds an option to bypass one of the two forks. The current systemd response to that can be tested by the -D flag (and redirecting the debug output, if necessary). No PID files should be created with either -F or -D. What I haven't had a chance to look at is whether systemd misinterprets the second fork (to create the unprivileged child) as an attempt to daemonize. Maybe I am confusing this with launchd testing - it's been a while.

@clepple, I haven't tried your code, but when running as Type=simple (the default) the daemon is not supposed to fork at all. From the documentation:

If set to simple (the default if neither Type= nor BusName=, but ExecStart= are specified), it is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units.

If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.

I would prefer that all of the daemons have similar options added at the same time

I also added this option to upsd and drivers now, adding this to upsdrvctl seems more complicated.

What I haven't had a chance to look at is whether systemd misinterprets the second fork (to create the unprivileged child) as an attempt to daemonize

I tried this and systemd correctly supervises both the parent and the child process

I rebased this PR on current master, is there anything else that's blocking this?

This PR was finally devoured by #683 which originally introduced related separation of debug vs backgrounding, as well as config-file provided debug levels.