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