Talk:Comparison of init systems
Detailed Feature Comparison Table
The tabular comparison appears to be biased negatively against sysvinit and upstart. It is copied from the systemd website.
|Hurting feature of systemd|
|Feature found elsewhere|
|Specific dependency without general interest|
|Mandatory DBus dependency||no||yes||yes||no||no|
|Hard-to-debug monolithic startup in undocumented C||no||no||yes||no||??|
|Modular C coded early boot services included||no||no||yes||optional||??|
|Socket-based Activation||no||no[note 2]||yes||no||no|
|Bus-based Activation||no||no[note 3]||yes||no||??|
|Device-based Activation||no||no[note 4]||yes||??||??|
|Configuration of device dependencies with udev rules||no||no||yes||??||no|
|Path-based Activation (inotify)||no||no||yes||no||no|
|Mount handling with service dependency||no||no[note 5]||yes||no||no|
|fsck handling with service dependency||no||no[note 5]||yes||no||no|
|Automount handling with service dependency||no||no||yes||no||no|
|Snapshotting of system state||no||no||yes||??||yes|
|Optionally kills remaining processes of users logging out||no||no||yes||no||no|
|Linux Control Groups Integration||no||no||yes||yes||no|
|Audit record generation for started services||no||no||yes||no||yes(?)|
|Encrypted hard disk handling (LUKS)||no||no||yes||yes||??|
|SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents||no||no||yes||mostly yes||??|
|Network Loopback device handling||no||no||yes||yes||yes|
|System-wide locale handling||no||no||yes||yes||??|
|Console and keyboard setup||no||no||yes||yes||??|
|Infrastructure for creating, removing, cleaning up of temporary and volatile files||no||no||yes||yes||??|
|Handling for /proc/sys sysctl||no||no||yes||yes||??|
|Save/restore random seed||no||no||yes||yes||??|
|Static loading of kernel modules||no||no||yes||yes||??|
|Automatic serial console handling||no||no||yes||??||??|
|Unique Machine ID handling||no||no||yes||yes||??|
|Dynamic host name and machine meta data handling||no||no||yes||??||??|
|Reliable termination of services||no||no||yes||yes||yes|
|Early boot /dev/log logging||no||no||yes||yes||yes(?)|
|Minimal kmsg-based syslog daemon for embedded use||no||no||yes||??||??|
|Respawning on service crash without losing connectivity||no||no||yes||??||yes|
|Gapless service upgrades||no||no||yes||??||??|
|Built-In Profiling and Tools||no||no||yes||yes (shell)||??|
|Remote access/Cluster support built into client tools||no||no||yes||no||no|
|Can list all processes of a service||no||no||yes||yes(cgroup)||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||yes||no|
|Automatic per-user cgroups||no||no||yes||??||no|
|SysV compatibility||yes||yes||yes||(which part?!)||yes|
|SysV services controllable like native services||yes||no||yes||no||??|
|Reexecution with full serialization of state||yes||no||yes||yes||??|
|Interactive boot-up||no[note 6]||no[note 6]||yes||yes||??|
|Container support (as advanced chroot() replacement)||no||no||yes||yes||yes|
|Dependency-based bootup||no[note 7]||no||yes||yes||yes|
|Disabling of services without editing files||yes||no||yes||yes||yes|
|Masking of services without editing files||no||no||yes||??||??|
|Robust system shutdown within PID 1||no||no||yes||wrong||??|
|Built-in kexec support||no||no||yes||yes||??|
|Dynamic service generation||no||no||yes||???||??|
|Upstream support in various other OS components||yes||no||yes||not needed||xx|
|Service files compatible between distributions||no||no||yes||yes||no|
|Signal delivery to services||no||no||yes||yes||yes|
|Reliable termination of user sessions before shutdown||no||no||yes||no||??|
|Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools||no||no||yes||yes||yes|
- Read-Ahead implementation for Upstart available in separate package ureadahead, requires non-standard kernel patch.
- Socket activation implementation for Upstart available as preview, lacks parallelization support hence entirely misses the point of socket activation.
- Bus activation implementation for Upstart posted as patch, not merged.
- udev device event bridge implementation for Upstart available as preview, forwards entire udev database into Upstart, not practical.
- Mount handling utility mountall for Upstart available in separate package, covers only boot-time mounts, very limited dependency system.
- Some distributions offer this implemented in shell.
- LSB init scripts support this, if they are used.
OpenRC bonus features
|multiple distributions using it||yes||yes||yes||yes|
|portable to non-x86 non-linux||yes||yes||NO||YES|
|parallel service startup||mostly-no||mostly-no||yes||yes|
|per-service resource limits (ulimit)||no||no||yes||yes|
|separation of code and configuration (init.d / conf.d / service.d )||mostly-yes||no||yes||yes|
|easily extensible startup scripts||yes||mostly-yes||yes||yes|
|un-principled license (BSD)||no||no||no||YES|
|stateful init scripts (is it started already?)||no||mostly-no||yes||yes|
|complex init scripts / targets to start multiple components (samba -> smbd nmbd, nfs ->)||yes||yes||yes||yes|
|automatic dependency calculation and service ordering||no||mostly-no||mostly-yes||mostly-yes|
|minimal dependencies and footprint (CC + posix + linux kdbus)||yes||yes||yes||yes|
|proper (whatever that means) integration into container/virtualization (linux-vserver, openvz, ...)||mostly-yes||mostly-yes||yes||yes|
|proper modular architecture and separation of optional components (cron, syslog)||yes||mostly-yes||yes||yes|
|expressive and flexible network handling (including vpn, bridges, ...)||??||??||yes||yes (if you ignore the bit about minimal dependencies and footprint)|
|support for bare-metal bare-dependency servers||yes||yes||yes||yes|
|verbose debug mode||yes||yes||mostly-no||yes|
My point here is that if somebody wants to really do a comparison they're better off sticking to facts and not value statements. Some of the above wasn't really accurate either - you can launch multiple daemons with a single systemd unit, as long as it pulls in other units, etc. We all have blogs - if we want to rant on about our favorite init systems, that seems like the better place to do it. The chart on the main page seems reasonably factual, at least. -- Rich
Size and complexity
|Version||File size||File count||Lines of code|
|OpenRC||0.9.3||n/a||sysvinit + 300 files||~30k lines, 3.3k posix sh, ~12k C|
|Upstart||1.5||n/a||285 files||~185k lines, ~97k C|
|Debian||n/a||n/a||sysvinit + 120 files||5.8k lines|
|systemd||v44+||n/a||dbus + glib + 900 files||224k lines, 125k C|
|sysvinit||n/a||560kB||75 files||~15k lines|
|D-Bus||n/a||11MB||~500 files||300k lines, 120k C|
|glib||n/a||72MB||~2500 files||~1.7M lines, ~430k C|
Debian startup is smallest, it's only shell with sysvinit (C) as dependency
Upstart is about 10 times bigger in terms of lines of code/text. Most of the extra complexity size comes from C.
OpenRC is about twice as big as debian startup. The size difference is mostly the OpenRC core written in C, which expands the footprint from ~3k LoC to ~15k LoC compared to shell.
systemd is about 10 times bigger, like upstart. But with the mandatory deps it blows up to about one hundred times the code footprint! Most of the extra code is in mandatory dependencies, but the systemd core is also bigger than anything else.
- This comparison is totally misguided. Fixing it would require much more work than simply running wc(1) on the source repository. The numbers for systemd above include udev and libraries for talking to it. That's also where glib comes from: it's used by gudev, a convenience wrapper around libudev. Additionally, there's a whole slew of commands (for debugging purposes, mostly) that have nothing to do with PID 1. Like generating bootchart graphs in SVG format. Then there's logind and various other stuff.
- One can certainly disagree with the systemd guys' preference for maintaining a bunch of loosely related stuff in a single git repository. It doesn't affect the complexity of the init system, though, and this is what this section is supposedly about.
- As it is, just running wc(1) on the src/ subtree of a repository (and this seems to be exactly how those numbers were achieved) and then drawing bogus conclusions doesn't provide any value at all. --Lsl (talk) 18:25, 5 February 2014 (UTC)
OpenRC parallel startup is an unstable feature
Acording to this comment on bug #391945:
"rc_parallel has always been considered an unstable feature of openrc. There was a very clear warning in rc.conf thatsetting rc_parallel=y can lock up your boot process.
rc_parallel=y is only to be used currently by developers and users who are willing to test the feature, and bugs against it are not considered release blockers.
I recommend removing any rc_parallel lines from your rc.conf unless you are comfortable with this risk."
I would like to change the "Yes (optional)" entry on the Parallel service startup / OpenRC cell, to "Yes (unstable)", with a link to the bug, if no one disagrees.
Update (version 0.12 and higher) The recent version of the OpenRC works with parallel setup quite nice, however there are exists corner cases in which OpenRC fails to work properly. In most of the cases problem is in init scripts themself and that are fixed when got discovered. Also openrc doesn't break dependency cycles well.