On Fri, Dec 20, 2013 at 03:03:25PM -0800, Russ Allbery wrote: > 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. The one benefit of not using sd_notify() is that it doesn't require introducing build-time dependencies or portability concerns; upstreams who may not use Linux at all can still validate the correctness of the SIGSTOP interface manually, and low barrier to entry for upstream is a good thing. But as Andi said, there's no real conceptual difference between the two approaches, and I don't see anything here that weighs in favor of one project over the other. Do you agree? If so, perhaps we should table this particular thread; we can always discuss the finer points of implementation outside the TC decision. Of course if you disagree, and feel this is a point that's relevant to the TC decision, I'd like to understand why. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
