Talk:Comparison of init systems

From Gentoo Wiki
Jump to: navigation, search

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
Pointless feature
sysvinit Upstart systemd OpenRC SMF
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  ??
Read-Ahead no no[note 1] yes no  ??
Socket-based Activation no no[note 2] yes no no[1]
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
Timer-based Activation cron/at cron/at proprietary cron/at cron/at
Mount handling with service dependency no no[note 5] yes no no
fsck handling with service dependency no no[note 5] yes no no
Quota handling no no yes  ??  ??
Automount handling with service dependency no no yes no no
Swap handling no no yes yes(?)  ??
Snapshotting of system state no no yes  ?? yes[2]
XDG_RUNTIME_DIR Support no no yes no  ??
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(?)
SELinux integration no no yes yes no
PAM integration no no yes 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
binfmt_misc handling no no yes yes no
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  ??
Plymouth integration no yes yes buggy no
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  ??  ??
Graphical UI no no yes no yes[3]
Built-In Profiling and Tools no no yes yes (shell)  ??
Instantiated services no yes yes yes yes
PolicyKit integration no no yes no no
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  ??
SysV-compatible /dev/initctl yes no yes yes  ??
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  ??
utmp/wtmp support yes yes yes yes  ??
Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools no no yes yes yes

— Preceding unsigned table largely based on contributions by Lu zero and Heroxbd.


  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. 5.0 5.1 Mount handling utility mountall for Upstart available in separate package, covers only boot-time mounts, very limited dependency system.
  6. 6.0 6.1 Some distributions offer this implemented in shell.
  7. LSB init scripts support this, if they are used.



OpenRC bonus features

sysvinit Upstart systemd OpenRC
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 ) mostly-yes no no yes
easily extensible startup scripts yes mostly-yes NO yes
friendly upstream yes no NO YES
friendly license (BSD) no no no YES
stateful init scripts (is it started already?) no mostly-no yes yes
complex init scripts to start multiple components (samba -> smbd nmbd, nfs ->) yes yes NO yes
automatic dependency calculation and service ordering no mostly-no mostly-yes yes
minimal dependencies and footprint (CC + posix sh) yes yes NO yes
proper integration into container/virtualization (linux-vserver, openvz, ...) mostly-yes mostly-yes  ??? yes
proper modular architecture and separation of optional components (cron, syslog) yes mostly-yes NO yes
expressive and flexible network handling (including vpn, bridges, ...)  ??  ?? mostly-no yes
support for bare-metal bare-dependency servers yes yes NO yes
verbose debug mode yes yes mostly-no yes

— Preceding unsigned table largely based on contributions by Patrick (talkcontribs)

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.

— Preceding unsigned comment added by Patrick (talkcontribs)

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.

— Preceding unsigned comment added by Canek (talkcontribs)

missing s6, runit, & busybox

Talk status
Outdated icon This discussion is still ongoing.

the article is missing s6, runit, & busybox. 666threesixes666 (talk) 18:59, 16 March 2014 (UTC)