Andreas Barth <[email protected]> writes: > * Russ Allbery ([email protected]) [131219 04:09]: >> Ian Jackson <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
