Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Ian Jackson <ijackson@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: