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.