Things that systemd gets right

December 10, 2012

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 go in /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, unlike Upstart.

  • 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 involve XML.

  • 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 to manageability.

  • 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.)

Written on 10 December 2012.
« When I'd use a web server other than Apache
The general lesson from the need for metrics »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Dec 10 00:39:34 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.