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.