[Started drafting this before Ian forked the bug; sending to both bug reports now] On Fri, Dec 20, 2013 at 03:41:55PM -0800, Russ Allbery wrote: > Ian Jackson <ijackson@chiark.greenend.org.uk> writes: > > Russ Allbery writes: > >> 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. > > I strongly disagreee. > > As the upstream author of a daemon I'm > > - not willing to add a library dependency for this > > - not willing to write a 50-100 lines of tiresome socket code for this > > - not willing to copy the library file into my source tree > > so the result is that userv upstream won't support systemd's readiness > > protocol. > Yes, we completely disagree. > Among other things, that's about the smallest and least-impactful library > dependency I can imagine. My intent in integrating support for sd_notify > is to just stub out the call when not built with systemd support, which is > pretty trivial to do with Autoconf and means that those who want systemd > integration get it and those who don't care can easily ignore it. The lowest-impact library dependency is still pretty large, from the perspective of the typical daemon upstream. Plenty of projects don't use autoconf. Some aren't written in C at all and would need bindings (or to reimplement the base logic natively). There is an elegance to sd_notify() that appeals to you, I can understand that. But as Ian's response demonstrates, it doesn't appeal to everybody. I think the next-generation init system should bring solutions that improve things for all consumers, not just to those maintainers for whom introducing an init-system-specific external library dependency is compatible with their sense of aesthetics. You say that both upstart and systemd are backwards-compatible, for those who don't want to adopt their respective readiness interfaces. That's true, but that just means backwards-compatibility with a world of bugs that we should strive to eliminate. There are all kinds of race conditions in the init scripts we have today in Debian, caused by improper daemonization (forking/detaching before listening, etc.). I think declaring that upstreams that don't want to use sd_notify() (or change to use socket-based activation) can just use the backwards-compatibility means we fall short of the kind of across-the-board uplift that we should seek to achieve. This discussion makes it clear to me that the SIGSTOP approach /also/ doesn't achieve that, due to equal but opposite aesthetic preferences on the part of different groups of maintainers. :) So I'm in favor of upstart implementing sd_notify, alongside its existing SIGSTOP handling. But I think it doesn't make sense to treat it as a mark against upstart, for Debian's purposes, that upstart started from the more conservative end of the spectrum on this question while systemd was more ambitious. If anything, the long time it's taken Debian to even seriously consider the question of moving to upstart shows that by at least one relevant measure, even upstart was being too aggressive. :/ -- 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/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature