Dear all,
Systemd[1] is the currently fashionable next-generation init
replacement, intended to replace both System V init and Ubuntu's
upstart. Since the Debian systemd package is now operational, I've
decided to try running it on my laptop. Here are my observations after
three days with systemd.
Please note that this mail is not intended to push Debian's policy in
one way or another, which would be premature. Note further that any
opinions expressed in this mail are mine, and mine only, and that they
are subject to change in the future as I grow older and more stupid.
The good
========
Systemd works
-------------
It is easy to get systemd to work on a Debian system. Just install the
systemd package, and reboot after adding "init=/bin/systemd" to the
kernel's command line. (I'm running testing, so I've had to pull a few
packages from sid to get systemd to install.)
In addition to the issues described on the wiki[1], I'm sufferring from
a deadlock on shutdown that is resolved by systemd timing out after
a couple of minutes.
Systemd is documented
---------------------
Systemd comes with extensive documentation, in the form of well-written
manual pages; additionally, there is a series of (somewhat verbose) blog
postings by the author that explain the rationale.
(The documentation does need more work, though. For example I couldn't
find the complete set of service states, and it took me some time to
discover how native and SV services interact.)
Systemd makes sense
-------------------
Unlike upstart, which I've never managed to get my head around, systemd
actually makes sense to me. It has a sane notion of dependency,
a relatively sane notion of service, a comprehensible notion of target
(the equivalent of a runlevel). While I may not like systemd's
obsession with socket activation, it too is a notion that makes sense.
Systemd got services right
--------------------------
What systemd definitely got right are services, in more than one way.
### Services are launched by init
With SV init, a deamon is launched by a descendant of whoever started
the initscript. The daemon may inherit file descriptors from somebody's
login shell, which may end up e.g. preventing a filesystem from getting
unmounted. (And no, CLOEXEC is not a solution.)
With systemd, services are launched by the init daemon, which has
hopefully been able to preserve a clean environment. (This is also the
case with all other modern init replacements, notably upstart and
runit.)
### Services have a sane life cycle
Systemd services have a sane life cycle, and are monitored by systemd in
a variety of ways. Thanks to cgroups, systemd is able to reliably kill
or restart a service -- no more rogue processes that are left after
you've stopped a daemon.
(Not everything is perfect, though. Systemd perpetuates SV init's
confusion between daemons -- things that keep running -- and
initialisation scripts -- things that must be run at some point during
the boot process, but don't really have a state.)
### Defining a service is a piece of cake
Writing a native service for systemd is a pleasure -- it's a matter of
writing a simple config file, in a human-readable syntax (no XML),
typically 3 to 6 lines long, and soft-linking it to the right place.
Compare that with SV init, where writing an init script takes the best
part of an hour and involves getting the syntax of start-stop-daemon
wrong at least three times.
Most of the features that you'd expect are present, including setuid,
redirecting output to syslog, resource limits etc. One thing that I've
found missing is the ability to redirect output to a log file in
a manner compatible with logrotate (without going through syslog), but
perhaps I haven't looked hard enough.
The format of a service definition is sane enough to allow for automatic
conversion to a different format; I think it would be quite doable to
automatically convert systemd's definitions to SV init scripts or to the
format of whatever is the next fashionable init replacement after
systemd.
### System V initscripts are monitored
Unlike all other init replacements known to me, systemd is able to
monitor daemons launched from System V init scripts just as reliably as
native services. This is an amazingly cool feature.
The bad
=======
Systemd is bloated
------------------
Systemd is bloated. It apparently attempts to take over the roles of
init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and
probably others. The result is that you end up running 50000 lines of
C code as PID 1, as compared to the 8000 lines of SV init or the 6000
lines of runit.
Systemd is layered strangely
----------------------------
For a low-level piece of infrastructure, systemd interacts with a lot of
high-level software; while this might be okay for a workstation running
Gnome, it makes me wonder whether it will be usable on servers.
A cursory look shows that systemd intrinsically depends on D-Bus (the
*desktop* bus) and knows about Plymouth, RedHat's implementation of
a splash screen. More on that below.
Systemd hard-wires special cases
--------------------------------
Rather than relying on distribution-specific shell scripts, systemd
hard-wires much of its behaviour in C code. The most shocking case,
already mentioned above, is that systemd interacts with Plymouth. This
is not done by using some generic early-boot protocol -- systemd
contains code that is explicitly meant to communicate with Plymouth, the
one and only implementation of a splash screen.
Another case that I've actually been bitten by is that systemd
hard-wires runlevel 5 in its SV init compatibility code; that's merely
inflexible under Fedora, but clearly wrong under Debian. (I've now
fixed my system to run the exact same initscripts in all four multi-user
runlevels.)
Systemd deprecates shell scripts
--------------------------------
With systemd, you're no longer supposed to write your service
definitions in shell; instead, you write them in systemd's declarative
language. Where you used to say
ulimit -d 40000000
you now say
LimitDATA = 40000000
The trouble with that is that while we all know how to write shell
scripts, systemd requires that we learn a new language. What is more,
we are now limited to configuring those aspects that systemd's author
has implemented; this is unlike shell scripts, where we can configure
anything that can be configured either from the shell or from a utility
callable from the shell. (Compare with runit, which simply ships with
a utility to change a bunch of process paramaters not otherwise
tweakable from the shell, and expects you to write a single-line shell
script in order to tweak process state.)
Systemd is Linux-specific
-------------------------
Systemd is specific to Linux. This is strange, since the only feature
of Linux used by systemd that doesn't have an exact equivalent on other
systems, cgroups, is optional in systemd.
Systemd's author is annoying
----------------------------
While I haven't had the pleasure to meet Lennart in private, I find his
public persona annoying, both on-line and at conferences. He practices
misleading advertising[2], likes to claim that the universal adoption of
systemd by all distributions is a done thing[3], and attempts to bully
anyone who has the gall to think that the discussion is still open[4].
Conclusion
==========
Systemd is the first init replacement worth criticising.
[1] http://wiki.debian.org/systemd
[2] See the comparative tables on http://0pointer.de/blog/projects/why.html .
They remind me of the advertising for Microsoft Quick C.
[3] "Since then most of the big distributions have decided to adopt it
in one way or another..." http://0pointer.de/blog/projects/why.html
[4] "Well, I guess we simply have to disagree. My interest is a tighly
integrated, small, minimal, lightweight system. Yours seem to be a big,
archaic, chaotic, redundant, resource intensive system. But that's
fine." http://osdir.com/ml/fedora-devel-list/2011-06/msg01065.html
Attachment:
pgpEiWPZGKaJl.pgp
Description: PGP signature