[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
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
]] 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
* 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
]] 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
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
]] 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
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
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
* 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
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,
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
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
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
* 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
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
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
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 /
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)
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
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
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.
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.
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
]] 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
25 matches
Mail list logo
