Re: Survey answers part 3: systemd is not portable and what this means for our ports
Henrique de Moraes Holschuh <hmh@debian.org> writes:
> How much of that improvement would be realised if we added a dependable,
> declarative (i.e. config-based instead of shell-script-based) service
> configuration support to sysvinit ?
Some, mostly on the maintenance side. I think the major short-term win is
eliminating the massive amounts of buggy shell boilerplate that make up a
typical init script, most of which are only trying to do something fairly
simple and easily describable in a declarative syntax.
However, that doesn't help with early boot ordering (for which you need
deep integration with kernel events), with boot speed and parallelization
(we made a lot of improvements with the dash switch and with our current
parallelization, but we can better), with tracking daemon processes and
getting rid of the fragile and annoying PID file dances or process table
searches, or, probably most significant in the long run, socket
activation. It mostly just helps Debian maintainers write better init
scripts, but it doesn't reposition us to take advantage of innovation in
daemon management and control.
That innovation is a big deal. The way we're handling daemons right now
is awful, and I think a lot of people don't realize it just because
they've never had experience with something better.
For example, here at Stanford, we've been using daemontools since shortly
after djb originally wrote it to manage many of the cases that init
scripts do an awful job at, and that experience has taught me just how bad
of a job init scripts do for a lot of common use cases. My coworkers spin
up new daemontools /service scripts all the time, and grumble mightily
when they have to write an init script instead because a /service script
won't work for some reason. It makes a huge difference. But daemontools
has a bunch of its own problems (as does runit) and are not general
replacements. systemd and upstart both do everything useful that those
tools do and much more.
This is something that's also been independently understood by other UNIX
vendors. For example, one of the major overhauls in Solaris 10 was
building in this sort of management framework for daemons, and (like a lot
of Solaris innovations) the idea was quite solid, even if the
implementation (XML, ew) was dubious. And of course Mac OS X has had
launchd for quite some time, which isn't quite as comprehensive of a
solution, but tackles some of the same problems.
Basically, Debian is seriously behind the curve on this, but we're so used
to our familiar, comfortable problems that we don't necessarily see the
amount of pain that we're enduring that we don't have to endure. As
Charles noted elsewhere on this thread, once you start looking at and
maintaining either systemd or upstart configurations instead of init
scripts, you realize what sort of rock you were beating your head against
and how nice it feels for the pain to stop.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: