Things that systemd gets right
On Twitter, I recently put forward the heretical opinion that systemd is actually a good thing (as I've written a bit about before). Now, systemd is not flawless or without worrisome tendencies and it has a number of features that I'm indifferent to, but I do think that it gets quite a lot of things right. Today I feel like trying to list them off (partly so that I have this in one place for future use).
(A disclaimer: this is from the perspective of someone who runs servers and thus doesn't really care about systemd features like minimizing boot time or not actually starting various sorts of programs until someone asks for them.)
To begin with, a terminology note. What systemd calls a unit is what we would otherwise call an init script (well, it's a superset of that, but we'll ignore that for now). I'll be using 'unit' and 'units' throughout this.
So, in no particular order:
- systemd has a strong separation between system-supplied units, which
/lib/systemd, and sysadmin-supplied units, which go in
/etc/systemd. This is very helpful for keeping track of the latter.
- you can override a system-supplied unit with a sysadmin-supplied one
without changing or removing the system-supplied one.
(Why, you would think that systemd was written by people who understood modern package management.)
- what units are enabled in various states is stored in the filesystem
in a visible form, not locked up in a magic database somewhere.
- you can have units installed without being activated,
- systemd allows units to shim themselves into the startup order so that
they get started before some other unit; you do not have to alter
the other unit to enable this (unlike Upstart again).
(systemd is not perfect here; in the general case you can't reorder existing units without editing some of them. But you can do this by overriding the system-supplied unit with your own copy, per above.)
- systemd unit configuration files are easy to write and easy to read
(cf); they contain almost the minimal
information necessary with very little extraneous fluff. They do not
- systemd handles a lot of annoying infrastructure for you; for example,
you do not have to arrange to daemonize programs you run.
- systemd starts and restarts services in a consistent and isolated
environment, not in whatever your
current environment is when you run the start and restart commands.
- systemd keeps track of what processes belong to a particular service,
so it can both list all the processes that are part of a service and
tell you what service a particular process is part of. This is a boon
- because it actively tracks unit status, conditional restarts are
not dangerous; it shares this behavior with
any competently implemented active init system.
(SysV init scripts are a passive system, Upstart, Solaris SMF, and systemd are all active ones.)
- during boot, systemd reports unit startups as they happen (and reports
if they succeeded or failed). You would think that this is a basic
feature that everyone has, but no; neither SMF nor Upstart do this.
- unit names are succinct (unlike SMF).
- it apparently does per-user fair share scheduling by default (but I haven't had a chance to run systemd in a situation where I could really see this in action).
In common with other active systems, systemd starts units in parallel when possible. I don't consider this a striking advantage, especially because other systems do it too.
(I may update this with additional things as they occur to me or as people mention them, since I've probably missed some.)
Sidebar: how I feel about the competition
The competition that I know of is SMF and Upstart. SMF is encrusted with complexity and dates from the days when people thought XML was a good idea; it is 'enterprisey' in a bad way. I consider it a step backwards from System V init scripts. Upstart is a flawed attempt and not bold enough; even ignoring the flaws, it isn't a significant enough improvement over SysV init scripts to be worth the pain of conversion.
(In other words, Upstart is an improvement but not a significant and worthwhile one.)
Comments on this page:Written on 10 December 2012.