Dmitry Bogatov <kact...@ruggedinbox.com> writes: > Not to start flame or to advertize anything/anyone, but why to integrate > with 'runit' init system, your program should support foreground > operation and logging on stdout, and to integrate with systemd, it > should link with library?
You should *also* support foreground operation and logging on stdout with systemd. Any modern daemon should support that mode of operation at least as an option. (I've been pushing for that for fifteen years, well before systemd started, since it makes a lot of daemon management much easier once you have something more sophisticated than rc.d shell scripts. I think djb's daemontools was one of the early advocates of this approach, but I suspect other people had independently invented the idea earlier.) To integrate with systemd, you don't have to use a library. However, the library lets you do some really cool stuff that makes a systemd system work more reliably. Most importantly (although not solely), it lets you explicitly tell systemd exactly when the daemon has fully started, so that the init system doesn't have to guess. All other init systems except upstart have to either guess or use a pretty awkward external signal (generally creation of a PID file on disk, which is otherwise useless if your init system tracks processes correctly and your daemon can run in the foreground). The guesses are often pretty bad, and a lot of daemons don't create the PID file at the right place because of various internal reasons. With systemd, this is nicely explicit. This, in turn, helps prevent a lot of irritating startup order race conditions and awkwardness, which under sysvinit caused Debian to have a bunch of "sleep N" commands embedded in init scripts to work around these races. This was always ugly, and had been something the distribution wanted to get rid of for a long time. upstart supports a similar mechanism via the -Z flag, but it's (IMO) a little less clean: the process sends itself a SIGSTOP when it's ready, and then lets the init system send it a SIGCONT. This does work, but I don't like it as much; pausing for the init system is awkward, you have to remember to omit the flag when running the daemon manually for debugging or you get really strange and unexpected behavior, and I think most long-time UNIX programmers have been burned by weird interactions with signals and are aware of how tricky they can be to use properly around event loops. systemd uses a UNIX domain socket (and you can implement the code yourself if you want, but the library makes it super-convenient and is well-tested code that other people maintain for you), which I think is a cleaner solution. The point is admittedly arguable. There's other stuff, like socket activation, that can be useful in some situations, but the explicit notification protocol was what sold me on adding optional libsystemd dependencies to the daemons I maintain. It's really a better solution than the other available options (which, to be clear, I also support as upstream, because that's my general philosophy on such things). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
