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