Why systemd?

systemd is still a young project, but it is not a baby anymore. The initial announcement I posted precisely a year ago. Since then most of the big distributions have decided to adopt it in one way or another, many smaller distributions have already switched. The first big distribution with systemd by default will be Fedora 15, due end of May. It is expected that the others will follow the lead a bit later (with one exception). Many embedded developers have already adopted it too, and there's even a company specializing on engineering and consulting services for systemd. In short: within one year systemd became a really successful project.

However, there are still folks who we haven't won over yet. If you fall into one of the following categories, then please have a look on the comparison of init systems below:

• You are working on an embedded project and are wondering whether it should be based on systemd.
• You are a user or administrator and wondering which distribution to pick, and are pondering whether it should be based on systemd or not.
• You are a user or administrator and wondering why your favourite distribution has switched to systemd, if everything already worked so well before.
• You are developing a distribution that hasn't switched yet, and you are wondering whether to invest the work and go systemd.

And even if you don't fall into any of these categories, you might still find the comparison interesting.

We'll be comparing the three most relevant init systems for Linux: sysvinit, Upstart and systemd. Of course there are other init systems in existance, but they play virtually no role in the big picture. Unless you run Android (which is a completely different beast anyway), you'll almost definitely run one of these three init systems on your Linux kernel. (OK, or busybox, but then you are basically not running any init system at all.) Unless you have a soft spot for exotic init systems there's little need to look further. Also, I am kinda lazy, and don't want to spend the time on analyzing those other systems in enough detail to be completely fair to them.

Speaking of fairness: I am of course one of the creators of systemd. I will try my best to be fair to the other two contenders, but in the end, take it with a grain of salt. I am sure though that should I be grossly unfair or otherwise incorrect somebody will point it out in the comments of this story, so consider having a look on those, before you put too much trust in what I say.

We'll look at the currently implemented features in a released version. Grand plans don't count.

General Features

sysvinit Upstart systemd

Interfacing via D-Bus no yes yes

Shell-free bootup no no yes

Modular C coded early boot services included no no yes

Read-Ahead no no[1] yes

Socket-based Activation no no[2] yes

Socket-based Activation: inetd compatibility no no[2] yes

Bus-based Activation no no[3] yes

Device-based Activation no no[4] yes

Configuration of device dependencies with udev rules no no yes

Path-based Activation (inotify) no no yes

Timer-based Activation no no yes

Mount handling no no[5] yes

fsck handling no no[5] yes

Quota handling no no yes

Automount handling no no yes

Swap handling no no yes

Snapshotting of system state no no yes

XDG_RUNTIME_DIR Support no no yes

Optionally kills remaining processes of users logging out no no yes

Linux Control Groups Integration no no yes

Audit record generation for started services no no yes

SELinux integration no no yes

PAM integration no no yes

Encrypted hard disk handling (LUKS) no no yes

SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents no no yes

Network Loopback device handling no no yes

binfmt_misc handling no no yes

System-wide locale handling no no yes

Console and keyboard setup no no yes

Infrastructure for creating, removing, cleaning up of temporary and volatile files no no yes

Handling for /proc/sys sysctl no no yes

Plymouth integration no yes yes

Save/restore random seed no no yes

Static loading of kernel modules no no yes

Automatic serial console handling no no yes

Unique Machine ID handling no no yes

Dynamic host name and machine meta data handling no no yes

Reliable termination of services no no yes

Early boot /dev/log logging no no yes

Minimal kmsg-based syslog daemon for embedded use no no yes

Respawning on service crash without losing connectivity no no yes

Gapless service upgrades no no yes

Graphical UI no no yes

Built-In Profiling and Tools no no yes

Instantiated services no yes yes

PolicyKit integration no no yes

Remote access/Cluster support built into client tools no no yes

Can list all processes of a service no no yes

Can identify service of a process no no yes

Automatic per-service CPU cgroups to even out CPU usage between them no no yes

Automatic per-user cgroups no no yes

SysV compatibility yes yes yes

SysV services controllable like native services yes no yes

SysV-compatible /dev/initctl yes no yes

Reexecution with full serialization of state yes no yes

Interactive boot-up no[6] no[6] yes

Container support (as advanced chroot() replacement) no no yes

Dependency-based bootup no[7] no yes

Disabling of services without editing files yes no yes

Masking of services without editing files no no yes

Robust system shutdown within PID 1 no no yes

Built-in kexec support no no yes

Dynamic service generation no no yes

Upstream support in various other OS components yes no yes

Service files compatible between distributions no no yes

Signal delivery to services no no yes

Reliable termination of user sessions before shutdown no no yes

utmp/wtmp support yes yes yes

Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools no no yes

[1] Read-Ahead implementation for Upstart available in separate package ureadahead, requires non-standard kernel patch.

[2] Socket activation implementation for Upstart available as preview, lacks parallelization support hence entirely misses the point of socket activation.

[3] Bus activation implementation for Upstart posted as patch, not merged.

[4] udev device event bridge implementation for Upstart available as preview, forwards entire udev database into Upstart, not practical.

[5] Mount handling utility mountall for Upstart available in separate package, covers only boot-time mounts, very limited dependency system.

[6] Some distributions offer this implemented in shell.

[7] LSB init scripts support this, if they are used.

Available Native Service Settings

sysvinit Upstart systemd

OOM Adjustment no yes[1] yes

Working Directory no yes yes

Root Directory (chroot()) no yes yes

Environment Variables no yes yes

Environment Variables from external file no no yes

Resource Limits no some[2] yes

umask no yes yes

User/Group/Supplementary Groups no no yes

IO Scheduling Class/Priority no no yes

CPU Scheduling Nice Value no yes yes

CPU Scheduling Policy/Priority no no yes

CPU Scheduling Reset on fork() control no no yes

CPU affinity no no yes

Timer Slack no no yes

Capabilities Control no no yes

Secure Bits Control no no yes

Control Group Control no no yes

High-level file system namespace control: making directories inacessible no no yes

High-level file system namespace control: making directories read-only no no yes

High-level file system namespace control: private /tmp no no yes

High-level file system namespace control: mount inheritance no no yes

Input on Console yes yes yes

Output on Syslog no no yes

Output on kmsg/dmesg no no yes

Output on arbitrary TTY no no yes

Kill signal control no no yes

Conditional execution: by identified CPU virtualization/container no no yes

Conditional execution: by file existance no no yes

Conditional execution: by security framework no no yes

Conditional execution: by kernel command line no no yes

[1] Upstart supports only the deprecated oom_score_adj mechanism, not the current oom_adj logic.

[2] Upstart lacks support for RLIMIT_RTTIME and RLIMIT_RTPRIO.

Note that some of these options are relatively easily added to SysV init scripts, by editing the shell sources. The table above focusses on easily accessible options that do not require source code editing.

Miscellaneous

sysvinit Upstart systemd

Maturity > 15 years 6 years 1 year

Specialized professional consulting and engineering services available no no yes

SCM Subversion Bazaar git

Copyright-assignment-free contributing yes no yes

Summary

As the tables above hopefully show in all clarity systemd has left behind both sysvinit and Upstart in almost every aspect. With the exception of the project's age/maturity systemd wins in every category. At this point in time it will be very hard for sysvinit and Upstart to catch up with the features systemd provides today. In one year we managed to push systemd forward much further than Upstart has been pushed in six.

It is our intention to drive forward the development of the Linux platform with systemd. In the next release cycle we will focus more strongly on providing the same features and speed improvement we already offer for the system to the user login session. This will bring much closer integration with the other parts of the OS and applications, making the most of the features the service manager provides, and making it available to login sessions. Certain components such as ConsoleKit will be made redundant by these upgrades, and services relying on them will be updated. The burden for maintaining these then obsolete components will be passed on the vendors who plan to continue to rely on them.

If you are wondering whether or not to adopt systemd, then systemd obviously wins when it comes to mere features. Of course that should not be the only aspect to keep in mind. In the long run, sticking with the existing infrastructure (such as ConsoleKit) comes at a price: porting work needs to take place, and additional maintainance work for bitrotting code needs to be done. Going it on your own means increased workload.

That said, adopting systemd is also not free. Especially if you made investments in the other two solutions adopting systemd means work. The basic work to adopt systemd is relatively minimal for porting over SysV systems (since compatibility is provided), but can mean substantial work when coming from Upstart. If you plan to go for a 100% systemd system without any SysV compatibility (recommended for embedded, long run goal for the big distributions) you need to be willing to invest some work to rewrite init scripts as simple systemd unit files.

systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system's userspace. It includes C rewrites of all basic early boot init scripts that are shipped with the various distributions. Especially for the embedded case adopting systemd provides you in one step with almost everything you need, and you can pick the modules you want. The other two init systems are singular individual components, which to be useful need a great number of additional components with differing interfaces. The emphasis of systemd to provide a platform instead of just a component allows for closer integration, and cleaner APIs. Sooner or later this will trickle up to the applications. Already, there are accepted XDG specifications (e.g. XDG basedir spec, more specifically XDG_RUNTIME_DIR) that are not supported on the other init systems.

systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike.

I believe that momentum is clearly with systemd. We invite you to join our community and be part of that momentum.