Re: libsystemd [was: Re: Is missing SysV-init support a bug?]
Dmitry Bogatov <kaction@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: