Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/why.html
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.