Bug#727708: upstart proposed policy in Debian [and 1 more messages]
[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 ijack...@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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Steve Langasek vor...@debian.org writes: 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). I still don't entirely agree with this, although the point about language bindings is certainly valid. (I'm tempted to just fix that problem for Perl, since no one seems to have to date, but that supports your point.) But I don't think there's a need to debate it, since as noted below I'm not sure it really matters. 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. :/ Note that I didn't include anything about the notification policy in my writeup. That's because after further consideration, I agreed: I don't consider this a notable advantage to either system. (I probably owe everyone an additional followup message listing some of the things that I don't think are differentiators, in part to call out what I consider exemplary support from multiple different projects over the course of this evaluation. I'm very grateful to both the upstart and the systemd teams for the work they've already done on integration and their responses during my discovery process.) -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Ian Jackson 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. Lennart provided http://fpaste.org/64821/32737713/ as a pretty minimal example of sd_notify which implements it in 18 lines of code. It lacks a little bit of error handling, but even with that, it's hardly 50-100 lines of tiresome socket code. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
* Tollef Fog Heen (tfh...@err.no) [131221 13:57]: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I'm not really happy by suggesting to copy files around. We have done that in the past too often, and it ends painful one way or other. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Russ Allbery Ian Jackson ijack...@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. sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Updating numerous copies of that code is not appealing. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Russ Allbery Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Sure. There's a tradeoff as always. I wanted to point out that embedding it is intentionally easy. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Updating numerous copies of that code is not appealing. I don't see why that should be considered a particularly significant downside though. Copies are usually worse than shared code, but not really worse than everything having a custom implementation. At least implementing sd_notify() support with a code copy should be considered a significant improvement over a daemon that always runs custom double-forking code. BTW it's worth noting that in the typical daemon case where readiness means the listening socket is ready to accept requests, the right way to convert the daemon to a new API is to use socket activation, which removes the need for separate start-up completion notification. Thus the need to use sd_notify() for this purpose should be the exception rather than the rule. This means that daemons which would use libsystemd-daemon for startup notification and nothing else (and would thus be potential candidates to abuse SIGSTOP) should be rare. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Uoti Urpala uoti.urp...@pp1.inet.fi writes: BTW it's worth noting that in the typical daemon case where readiness means the listening socket is ready to accept requests, the right way to convert the daemon to a new API is to use socket activation, which removes the need for separate start-up completion notification. Thus the need to use sd_notify() for this purpose should be the exception rather than the rule. This means that daemons which would use libsystemd-daemon for startup notification and nothing else (and would thus be potential candidates to abuse SIGSTOP) should be rare. Good point. Anything that's using socket activation probably doesn't really need additional synchronization. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
* 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.) Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Russ Allbery writes (Bug#727708: upstart proposed policy in Debian [and 1 more messages]): 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. Luckily the systemd socket activation is less fiddly than the general readiness protcol, so for systemd I am doing that instead. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Steve Langasek writes (Bug#727708: upstart proposed policy in Debian [and 1 more messages]): Of course if you disagree, and feel this is a point that's relevant to the TC decision, I'd like to understand why. I think it's relevant to the TC decision. Also relevant is the response from systemd upstream to the request to support this protocol as an option. I found it unsatisfactory. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
* Ian Jackson (ijack...@chiark.greenend.org.uk) [131221 00:33]: Steve Langasek writes (Bug#727708: upstart proposed policy in Debian [and 1 more messages]): Of course if you disagree, and feel this is a point that's relevant to the TC decision, I'd like to understand why. I think it's relevant to the TC decision. As I think that both protocols have their own advantages (and currently I don't think that any is so much better that we have to take it) I don't think it is relevant which of the protocols is supported right now. However I think it is relevant if we could get an patch integrated to support the other protocol as well (means: not replacing the current protocol). Which might be a good thing anyways as both protocols have their own merits. Also relevant is the response from systemd upstream to the request to support this protocol as an option. I found it unsatisfactory. You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ? Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Steve Langasek vor...@debian.org writes: 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? No -- for me, this is a plus in the systemd column over upstart, and likely will have an effect on my vote. Of course if you disagree, and feel this is a point that's relevant to the TC decision, I'd like to understand why. I don't think the upstart synchronization approach has a future. It's basically a hack to work around only the lack of synchronization, and all it can deliver is a single bit of data. The problem is that there may be more than a single bit of data that needs to be delivered. There may be multiple synchronization points, there may be more information that the daemon wants to tell its management process (the existing status reporting interface is an example), and so on. But there's no way to extend SIGSTOP. The systemd approach, while necessarily requiring a more complex communications protocol, is clealy extensible for future needs as they arise. This is consistent with a pattern that I'm seeing when evaluating the core init system functionality between systemd and upstart. upstart takes a very conservative approach of only addressing known problems and doing so in a fairly limited way. systemd takes a broader approach of trying to understand the general problem and trying to create a way to write daemons and other startup code that can be much simpler once systemd interfaces are available. There are pluses and minuses to those approaches, but given that both projects are maintaining backward compatibility, and given that I find myself generally nodding along with the systemd design decisions, I think the systemd approach is more interesting and has more long-term upside potential. upstart as it exists right now would solve a bunch of problems for us, but not lay groundwork for solving more problems in the future. systemd would both solve an equivalent set of problems and provide a path forward towards making the overall system much more robust, and given the breadth of the existing systemd deployment, it's likely that our upstreams are going to start adding that support. It's a more appealing picture. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson ijack...@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. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Andreas Barth a...@ayous.org writes: * Ian Jackson (ijack...@chiark.greenend.org.uk) [131221 00:33]: Also relevant is the response from systemd upstream to the request to support this protocol as an option. I found it unsatisfactory. You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ? Lennart here manages to put into words several of the things that I thought when I first heard about this method and didn't express as well: SIGSTOP is a mechanism for stopping processes, not for notifying service readiness. We shouldn't attempt to overload OS functionality like this, as SIGSTOP might happen for it's real purpose too. [...] Another big problem with raise(SIGSTOP) is that if done on an init system that can't handle it will result in a freeze. OTOH sd_notify() handles this gracefully and just becomes a NOP. I basically agree with his response here. If I were him, I probably would have added support for it anyway just on the grounds of supporting a mechanism that's already widely used in a major Linux distribution, but I understand his reluctance and, had I added it, I would have marked it as discouraged and documented why. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Russ Allbery r...@debian.org writes: 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. Sorry, that should have been daemon(7). -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Andreas Barth writes (Bug#727708: upstart proposed policy in Debian [and 1 more messages]): However I think it is relevant if we could get an patch integrated to support the other protocol as well (means: not replacing the current protocol). Which might be a good thing anyways as both protocols have their own merits. Yes, I agree that this is relevant. Also relevant is the response from systemd upstream to the request to support this protocol as an option. I found it unsatisfactory. You mean #732157 / https://bugzilla.redhat.com/show_bug.cgi?id=833105 ? Yes. I agree with the comments from Vincent and Niklaus. For me, Zbigniew's response shows where this approach leads and I don't find it attractive. I found Lennart's comments tendentious and his complaint about an admin's potential use of SIGSTOP (during startup) unconvincing (and easily resolved by the use of (say) SIGTTOU instead). I don't see the merit in extensibility; or rather, I think that there is room in the world for a non-extensible but trivial protocol. (And there are other potential simple protocols which would be more extensible.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson ijack...@chiark.greenend.org.uk writes: I don't see the merit in extensibility; or rather, I think that there is room in the world for a non-extensible but trivial protocol. (And there are other potential simple protocols which would be more extensible.) Well, the extensibility is already providing another obviously-useful feature, namely the watchdog support, which is done over the same channel. How do you think that should be implemented in upstart? It seems like a good example of a place where a daemon needs an ongoing communication channel with the init system. And you're never going to convince me that repurposing SIGSTOP to mean go is anything other than a hack. Sorry. :) I agree that it's a useful hack with low impact when patching upstream source, but it's still exactly the sort of repurposing of one thing to mean something entirely unrelated that tends to create problems and undermine guarantees that unknown other parties might be depending on. It makes the standards writer in me cringe. I personally have used kill -STOP on daemons started by init before as a systems administrator, usually when setting up debugging and sometimes when trying to temporarily pause a daemon while I figure out what's going on with a load issue without terminating it entirely and losing state. I believe it's also the first step of a gdb attach. The argument that admins may use this for other purposes is not theoretical. SIGSTOP is very useful because it's uncatchable, so you know that daemons with weird signal handlers can't make it ineffective. It always works the same in every situation (except, now, with daemons started by upstart). This is not true of SIGTTOU. Now, that being said, upstart only cares about SIGSTOP when the job hasn't yet signaled that it's ready, so this is only an issue if you try to attach during the early startup stage. That's not an entirely impossible situation, but less likely and not one of the cases where I've done this as an administrator before. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Russ Allbery writes (Bug#727708: upstart proposed policy in Debian): Is there a more complete explanation of this somewhere? The cookbook is rather short on details. It's documented in upstart's init(5) under expect stop. http://manpages.debian.net/cgi-bin/man.cgi?query=initsektion=5apropos=0manpath=Debian+testing+jessielocale= Assuming that this means the daemon sends SIGSTOP to itself when it's ready to accept connections, I find this completely counter-intuitive and exceedingly strange. Wouldn't this cause the daemon, if run outside of upstart, to do nothing in an extremely confusing fashion? I assume upstart is using waitpid to wait for the child to be stopped and is sending SIGCONT, and if you run the daemon outside of that environment, it would just stop itself and never start again. The daemon only does this if you tell it to, typically with a command line option. If you were to run it with that option from the shell, your shell would report that the daemon had stopped much as if you had ^Z'd it (although ^Z generates SIGTSTP). Russ Allbery writes (Bug#727708: upstart proposed policy in Debian): Ian Jackson ijack...@chiark.greenend.org.uk writes: It comes with being the daemon's parent, even - the special powers of pid 1 aren't even needed. I'm not sure that I understand. This is in the context of handling daemons that fork and background themselves, is not it? No. It's in the context of daemons which are written (well, have been modified) _not_ to fork. They just run as children of the supervisor. It's a way for a daemon to signal that it is ready. Running daemons directly as children of the supervisor is not a new idea: inetd does it for network servers (although it gets the logging wrong) and Dan Bernstein's daemontools work this way too. 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. If so, no normal parent would be able to detect that this has happened because the process would have already been reparented by init before the SIGSTOP signal is sent. So it does rely on the special properties of PID 1, namely its adoption of all processes that have abandoned their parent process. The SIGSTOP protocol is an alternative to the traditional daemon(3) call. daemon(3) is IMO at the root of the problem with sysvinit. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson ijack...@chiark.greenend.org.uk writes: No. It's in the context of daemons which are written (well, have been modified) _not_ to fork. They just run as children of the supervisor. It's a way for a daemon to signal that it is ready. Oh, I see, I misunderstood the context. (Although correct me if I'm wrong, but it sounded like this also worked for forking daemons.) 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. SIGSTOP is simpler in that no build system changes are required. I can see the appeal. I do find the use of the signal for that purpose profoundly weird, though, and it's rather annoying that you have to add an environment variable or command-line option (and hence more complexity). The systemd approach adds a shared library dependency but reduces code complexity, since you can just make that call unconditionally and not care if you're running outside of a systemd environment (where it will just quietly do nothing). sd_notify has a few other rather neat features for daemons that are systemd-aware, none of which are horribly important but which I will probably now start adding to some stuff since I think they're useful. The watchdog stuff in particular strikes me as similar to socket activation: something that requires a lot of upstream cooperation to use well, but which could really improve the state of play for daemon management when used well. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson ijack...@chiark.greenend.org.uk writes: Running daemons directly as children of the supervisor is not a new idea: inetd does it for network servers (although it gets the logging wrong) and Dan Bernstein's daemontools work this way too. Oh, and I should note that I've been using daemontools since very shortly after djb wrote it and continue using it to this day for some things, so you definitely don't have to convince me of the merits of non-forking daemons. I'm in complete agreement. -- 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
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Ian Jackson 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. Note that this is only if you need socket activation or a synchronisation point. If you don't have other services depending on the service in question, just omit Type from the systemd unit and it'll default to simple (aka «run in the foreground»). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
