Anthony Towns <a...@erisian.com.au> writes:
> On Jan 5, 2014 2:39 AM, "Russ Allbery" <r...@debian.org> wrote:
>> I'm doubtful that either of us are going to convince the other on this
>> point. I don't consider it comparable to the other examples you're
>> citing, and I think it's inobvious that raise(SIGSTOP) is a good
>> technical choice. Simple, yes, but that's not the same thing.
> How hard would it be to write an external wrapper that converts the
> systemd style socket activation to the SIGSTOP protocol (for upstart
> invoking a systemd compatible daemon)?
The wrapper would need to stay running for the life of the daemon, since
it would be the PID that the init system would track. That has some
drawbacks. For example, it would need to carefully pass signals along to
its child process. I've written code like that before, and it mostly
works for me, but I've not hammered on it very hard.
Although, hm... actually, maybe it wouldn't need to stay running for the
life of the daemon if it's sufficiently devious. The wrapper could fork
and then exec the daemon in the *parent*, and have the *child* listen for
the notification message and then kill(SIGSTOP) its parent and immediately
exit. I wonder if that would actually work....
Apart from that, it would need some UNIX socket (or abstract namespace
socket) code, but I don't think it's anything particularly complicated.
> Or to add support to start-stop-daemon for both protocols so a reliable
> sysv style script is trivial for more modern daemons?
The hard part for more general support would be socket activation,
particularly where you would put the configuration for how to create and
bind the sockets. See:
http://www.freedesktop.org/software/systemd/man/systemd.socket.html
for an idea of what configuration parameters you'd need to support and
that would need to be adjustable by the local systems administrator. Some
of those are not broadly useful or are addressing some specific edge
cases, but at least with networking sockets it's useful to have control
over a surprisingly large number of different parameters.
For just the notification part, it would probably be something one would
build on top of start-stop-daemon's -b support. It should be possible to
address the documented weakness of -b, and it should be doable, but it's a
bit more complicated. Essentially, start-stop-daemon would need to
implement not only the server side of the notification protocols (the
waitpid and kill(SIGCONT), plus the UNIX socket stuff), but also
separately be able to do much of the stuff described in the first section
of:
http://www.freedesktop.org/software/systemd/man/daemon.html
I do disagree mildly with that documentation in a few places -- I'm
dubious about changing umask, in particular -- but it's a pretty good
summary of proper behavior for a fork and exit daemon.
--
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
