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

Comments on this page:

From at 2012-12-10 12:37:16:

couldn't agree more strongly with your arguments. and, in particular, the fact that they didn't choose XML speaks volumes. XML is unreadable (but easy to parse). /mark

From at 2012-12-11 05:34:35:

couple of observations:

1) smf can print messages for every service being started and if it failed or not, the default is it doesn't but you can change it. By default it will print information to a console if a service failed though.

2) about service names - apart from what vendor provided, you are free to name them as you wish

I like both (systemd and smf) - smf is more mature though and it just does the job. The xml part - I know some people don't like it but for me it doesn't matter and it is easy to manipulate them. Or you can use svcboundle tool provided in Solaris 11 to generate them for you.

Another feature I like in SMF (not sure if systemd has it) is that for different service transistions it can generate an email or snmp trap. Not to mention very nice integration with privileges to define start/stop context, etc.

By cks at 2012-12-11 10:07:59:

SMF's ability to be verbose is not well documented, at least in the Solaris 10 manpages. Ie, I couldn't find any clear mention of it in anything obvious. Perhaps it is hiding somewhere where experienced SMF people understand the implications of something the manpage says; if so, I consider this a documentation failure.

Vendor service names are exactly the service names that generally matter because those are the ones that one generally manipulates.

From at 2012-12-11 19:12:30:

It is documented in at least couple of places, for example svc.startd(1M)

" boot_messages

An astring (as defined in scf_value_is_type; see scf_value_create(3SCF)) that describes the default level of messages to print to the console during boot. The supported message options include quiet and verbose. The quiet option prints minimal messages to console during boot. The verbose option prints a single message per service started to indicate success or failure. You can use the boot -m option to override the boot_messages setting at boot time. See kernel(1M).


Regarding vendor provided smf names, what's wrong with the most commonly used ones like:


and yes, you can use shorter names if it is unique, for example just: ssh, ntp, zones, etc.

From at 2012-12-13 21:07:40:

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

Not entirely true - if you want to order e.g. "tor.service after" (and there's not After= line in tor.service or Before= in target), you can just create "", add "" "Before=tor.service" lines to it and then enable it.

That will work for boot, but if you need to (re-)start service later with proper ordering of it's deps, then you also add WantedBy= to symlink that custom target to "tor.service.wants" in /etc. With that, starting "tor.service" will pull in whatever ordering and extra deps you define on that custom target.

I'd say no overriding yet.

Of course, ".include ..." in /etc units seem to be generally safe and upstream-friendly way to do that same thing as well.

By cks at 2012-12-13 22:13:58:

The general case I was thinking of is when one service already has an explicit dependency on the other one (either direct or indirect) and you want to flip the order. As you note, if there's no explicit order you can achieve this by adding a synthetic service to force the ordering you want with dependencies.

(In SysV init you could do this because ordering was implicit in sysadmin-maintained symlinks.)

(PS: I've used magic site-admin powers to modify formatting of the previous two comments so that they don't have hugely long lines of preformatted text. I'm mentioning this because I feel I should note whenever I modify comments.)

From at 2012-12-17 06:22:58:

And don't forget, systemd exposes every single tuning knob provided by modern linux kernel. IO priority, cgroups, scheduling class and anything you can think of is easily accessible for sysadmin. -zdz

From at 2013-01-22 17:59:58:


Nice article. One correction though: we don't do per-user, but per-service fair scheduling by default. We'd like to enable it per-user too, but this currently breaks real-time scheduling for user applications, so we don't do this. For a longer explanation see this:

And regarding the comment from "": with systemd git (soon to be released as 198) we actually have a much nicer solution for that problem. You can now drop-in files in /etc that can extend any unit file without having to edit the unit file. i.e. it is sufficient to drop a snippet with the setting you want to make in /etc/systemd/system/foobar.service.d/waldo.conf and that's it. You don't have to use .include anymore, don't have to copy any file, and don't create any stub units.


From at 2013-01-22 18:02:54:

Oh, and I am actually particularly interested in comparisons with SMF, especially by people who actually use it to a non-trivial amount. I am particularly interested in areas where systemd is doing worse than SMF, so that we can improve that. We are happy for any feedback so we can make systemd better, especially on this topic.


From at 2013-01-23 04:24:56:

You missed one good concurrent. There is OpenRC which uses simplified shell like init scripts yet it has similar features to systemd (paralelization, cgroups, ...) and is still portable ;-)

From at 2013-01-23 08:57:34:

Parallelization in OpenRC does not work: so it is unfair to treat it as having the same features.

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, View Normal, Add Comment.
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.