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=init&sektion=5&ap

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Ian Jackson 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,

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Ian Jackson 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

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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

* Russ Allbery (r...@debian.org) [131219 04:09]: > Ian Jackson 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 c

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Andreas Barth writes: > * Russ Allbery (r...@debian.org) [131219 04:09]: >> Ian Jackson 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

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 writes: > > * Russ Allbery (r...@debian.org) [131219 04:09]: > >> Ian Jackson writes: > >>> systemd supports the non-forking daemon too. Only, instead of > >>> raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket

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 i

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. Als

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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Steve Langasek 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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Ian Jackson 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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Andreas Barth 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=833

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Russ Allbery 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)

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 th

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Ian Jackson 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 o

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

]] Russ Allbery > Ian Jackson 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

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Tollef Fog Heen 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 check

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

]] Russ Allbery > Tollef Fog Heen 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

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 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 pu

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Uoti Urpala 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 notific

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 h

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 suppor

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 writes: > > Russ Allbery writes: > >> I'd like to see both of them support systemd's method, since it's > >> extensible and provides more

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

Steve Langasek 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 do