Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Andreas Barth <aba@ayous.org> writes:
> * Russ Allbery (rra@debian.org) [131219 04:09]:
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>>> systemd supports the non-forking daemon too. Only, instead of
>>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an
>>> environment variable, connect to it, and send a special message with
>>> socket credentials attached.
>> I assume this is functionality provided by the libsystemd-daemon
>> library if you're willing to have a dependency on it? (Checks.) Ah,
>> yes, this is one of the things that sd_notify is for.
> I don't think this is a conceptual difference, but both inits would be
> able to work either way without changing their basic concepts. So if we
> have strong reasons to prefer one above the other this could also mean
> convincing upstream to implement the second approach. (It also could of
> course mean that there are too many things to adjust.)
Agreed.
I'd like to see both of them support systemd's method, since it's
extensible and provides more general functionality. I think the benefit
of support for SIGSTOP is marginal; adding sd_notify calls is not that
much harder and doesn't have the conceptual weirdness of stopping the
daemon to notify the init system that it's running.
Overall, I think the approach outlined in daemon(3) is more
forward-looking and thoughtful upstart's more conservative approach, and I
like the long-term vision. (Not horribly surprising, since it's an
evolution of the vision that daemontools represented early on, and which I
became convinced of some time ago.) It's going to take a lot of upstream
work to get there, and a lot of older or abandoned upstreams may not adopt
it fully, but it provides incremental benefits as more daemons are
switched over to a simpler and saner model that has clearly-defined and
well-specified synchronization points.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: