Bug#727708: requirement of non-forking startup protocol
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> | 8. Policy rules for support for init systems must:
> |
> | (a) Specify the use of a non-forking startup protocol (for
> | upstart and systemd),
> I'm not sure about upstart, but systemd is perfectly happy with daemons
> which double fork (Type=forking in systemd parlance). It is mildly
> discouraged, because:
> 1. it is hard to get right
> 2. it is more code than the other options
> 3. it is easier to start the program manually if non-forking protocol is used
> For new code, other protocols are certainly better. But for existing
> daemons which work correctly, points 1 and 2 don't matter, and 3 is not
> important enough.
> This requirement might force mantainers to modify some hairy
> internals in the startup code of daemons to avoid double forking. This
> seems pointless, as in most cases it wouldn't result in any noticable
> difference in speed or behaviour or correctness.
> I think this should be changed to:
> | 8. Policy rules for support for init systems must:
> |
> | (a) Encourage the use of a non-forking startup protocol (for
> | upstart and systemd),
Yeah, this is a good point. Since systemd uses the daemon-written PID
file for tracking forking daemons, it doesn't have the same issues as the
upstart expect fork or expect daemon protocols. Obviously, an external
PID file is not ideal, but it will work fine with systemd. (Now, daemons
that don't support a daemon-written PID file either will require
modifications, but even there, patching the daemon to write a PID file may
be less intrusive than patching it to change the startup behavior.)
I think upstart doesn't have a similar capability to use an external PID
file to figure out what process it should track, so we may have to keep
this restriction for upstart if we really want to get rid of expect fork
and expect daemon.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: