here he is Mr Poettering in 2014 explaining systemd and why it ought to be soooo complex.

with all decision making, it should be rational and fact and reason based and then stick to it (aka systemA boots faster than systemB, but systemB is easier in maintenance… etc.) whatever it might be.

while test running debian linux journald uses almost 100% cpu…

“The daemon will implicitly collect numerous metadata fields for each log messages in a secure and unfakeable way. See systemd.journal-fields(7) for more information about the collected metadata.”

systemd: Using the journal

update: systemd blanks NetFlix X-D

security problems: non-root to root escalation:

systemd examples:

tested on:

    Virtualization: kvm
  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 5.1.X
      Architecture: x86-64

one’s favorite way:

  • one can scroll up and down through the services
  • see their status
  • search for a particular status or service with /searchterm
    • possible search terms: running, active, failed, exited

systemctl|less; # list all services
systemctl list-unit-files; # list all services
UNIT FILE                                     STATE   
proc-sys-fs-binfmt_misc.automount             static  
dev-hugepages.mount                           static  
dev-mqueue.mount                              static  
proc-sys-fs-binfmt_misc.mount                 static  
sys-fs-fuse-connections.mount                 static  
sys-kernel-config.mount                       static  
sys-kernel-debug.mount                        static  
tmp.mount                                     disabled
brandbot.path                                 disabled
systemd-ask-password-console.path             static  
systemd-ask-password-plymouth.path            static  
systemd-ask-password-wall.path                static  
session-1.scope                               static  
session-c1.scope                              static  
arp-ethers.service                            disabled
auditd.service                                enabled 
autovt@.service                               enabled 

“enabled” means this service will start on boot.

“disabled” means this service will not start on boot.

“static” means the service is missing the [Install] section in its init script, so you cannot enable or disable it. Static services are usually dependencies of other services, and are controlled automatically. You can see this in the ClamAV example, as clamd@.service is a dependency of clamd@scan.service, and it runs only when clamd@scan.service runs.

list all enabled services (that will start on boot)

alias grep='grep --color'; # recommend add color to the output
systemctl list-unit-files | grep enabled; # list all enabled services
systemctl|grep running; # list all currently 
running services
auditd.service                                enabled 
autovt@.service                               enabled 
chronyd.service                               enabled 
clamd.service                                 enabled 
crond.service                                 enabled 
csf.service                                   enabled 
dbus-org.freedesktop.NetworkManager.service   enabled 
dbus-org.freedesktop.nm-dispatcher.service    enabled 
dovecot.service                               enabled 
exim.service                                  enabled 
getty@.service                                enabled 
httpd.service                                 enabled 
iptables.service                              enabled 
irqbalance.service                            enabled 
kdump.service                                 enabled 
lfd.service                                   enabled 
lvm2-monitor.service                          enabled 
microcode.service                             enabled 
NetworkManager-dispatcher.service             enabled 
NetworkManager-wait-online.service            enabled 
NetworkManager.service                        enabled 
rhel-autorelabel.service                      enabled 
rhel-configure.service                        enabled 
rhel-dmesg.service                            enabled 
rhel-domainname.service                       enabled 
rhel-import-state.service                     enabled 
rhel-loadmodules.service                      enabled 
rhel-readonly.service                         enabled 
rsyslog.service                               enabled 
spamassassin.service                          enabled 
sshd.service                                  enabled 
systemd-readahead-collect.service             enabled 
systemd-readahead-drop.service                enabled 
systemd-readahead-replay.service              enabled 
tuned.service                                 enabled 
dm-event.socket                               enabled 
lvm2-lvmetad.socket                           enabled 
lvm2-lvmpolld.socket                          enabled                                enabled                             enabled                              enabled                              enabled                              enabled                              enabled

service resource usage:

systemd-cgtop – what service is using how much hardware resources cpu tasks memory:


systemctl status; # output process tree

    State: degraded
     Jobs: 0 queued
   Failed: 1 units
    Since: Sun 2019-09-22 14:19:35 CEST; 29min ago
   CGroup: /
           ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
           │ └─user-0.slice
           │   ├─session-c1.scope
           │   │ ├─4417 su - root
           │   │ ├─4431 -bash
           │   │ ├─5879 systemctl status
           │   │ └─5880 less
           │   └─session-1.scope
           │     ├─2755 login -- root     
           │     ├─3068 -bash
             │ └─1952 /usr/sbin/irqbalance --foreground
             │ └─1690 /usr/lib/systemd/systemd-udevd
             │ ├─2440 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
             │ ├─2441 nginx: worker process                   
             │ ├─2442 nginx: worker process                   
             │ ├─2443 nginx: worker process                   
             │ ├─2444 nginx: worker process                   
             │ └─2445 nginx: cache manager process            

# show status of a service
systemctl status lighttpd
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-06-01 15:09:13 EDT; 2min 34s ago
 Main PID: 529 (lighttpd)
    Tasks: 1 (limit: 2354)
   Memory: 7.1M
   CGroup: /system.slice/lighttpd.service
           └─529 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

Jun 01 15:09:13 hostname systemd[1]: Starting Lighttpd Daemon...
Jun 01 15:09:13 hostname lighttpd[504]: 2020-06-01 15:09:13: (configfile-glue.c.46) DEPRECATED: don't set server options in conditionals, variable: server.errorlog
Jun 01 15:09:13 hostname lighttpd[504]: 2020-06-01 15:09:13: (server.c.1493) WARNING: unknown config-key: accesslog.filename (ignored)
Jun 01 15:09:13 hostname systemd[1]: Started Lighttpd Daemon.
Jun 01 15:09:13 hostname lighttpd[529]: 2020-06-01 15:09:13: (configfile-glue.c.46) DEPRECATED: don't set server options in conditionals, variable: server.errorlog

systemctl list-units --type mount; # list all mount related units
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
-.mount                        loaded active mounted /
boot.mount                     loaded active mounted /boot
dev-hugepages.mount            loaded active mounted Huge Pages File System
dev-mqueue.mount               loaded active mounted POSIX Message Queue File System
home.mount                     loaded active mounted /home
proc-sys-fs-binfmt_misc.mount  loaded active mounted Arbitrary Executable File Formats File System
run-user-0.mount               loaded active mounted /run/user/0
run-user-1000.mount            loaded active mounted /run/user/1000
sys-kernel-config.mount        loaded active mounted Configuration File System
sys-kernel-debug-tracing.mount loaded active mounted /sys/kernel/debug/tracing
sys-kernel-debug.mount         loaded active mounted Debug File System

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

11 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

a bit of software philosophy

unix philosophy – keep it small and beautiful.

Despite the fact – that the catholic church claims that it’s pope is “infallible” – only God and Nobody is perfect (makes no mistakes).

A lot of people would like to be God – but face it – no human being is God – and no human being wants to be a Nobody.

Usually everybody wants to have meaningful relationships with the rest of mankind. Because of that errors are not the exception – they are the rule of whatever humans do.

There is no 100% perfect design, system or software – usually mankind settles with 99% error-free perfection as sufficient enough and goes on to the next task… 

One of systemd’s main goals is to unify basic Linux configurations and service behaviors across all distributions.[6]

About systemd

the program – that does it all – it will even cook you dinner if you configure it properly – problem of the “does it all”… complexity (the opposite of the UNIX philosophy of K.I.S.S  (keep it simple, stupid), because complexity mean: errors – error mean problems and thus: complexity shall be avoided (by anyone except God, but surely by the Pope as well)

apt-cache show systemd

“Description-en: system and service manager systemd is a system and service manager for Linux.

It provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.

systemd is compatible with SysV and LSB init scripts and can work as a drop-in replacement for sysvinit.

Installing the systemd package will not switch your init system unless you boot with init=/bin/systemd or install systemd-sysv in addition.”

Systemd was written by Lennart Poettering, Kay Sievers (Red Hat Inc.) and others in C and released under the GNU Lesser General Public License (LGPL).

While in 2010/2011 Sys-V-Init was replaced by upstart – shortly after – upstart was replaced by systemd – promising faster bootup and less RAM usage – now in 2017 – SUSE12, CENTOS7, Debian8 all use systemd as default initialisator and runlevel-manager.

Btw. runlevels will be renamed to “targets” in systemd.

So in a short period of time – things changed dramatically.

But well i if you can speed up or simplify (optimize) often (by many users) repeated tasks – the huge effort is worth it.

Because the more often a step is needed/repeated – the more important it is to be optimized and the bigger the productivity gaining effects of that optimization… but first you will need to know what tasks are performed often by your users?

While on servers startup-time might not be sooooo important – on a desktop system – it is pretty nice having an immediate result after pushing the power button.

systemd demystified

Is it a bug – or a feature?

social competence(social skills such as face2face-communication) is a rare good on this planet – and especially in tech-heavy industries such as computers – where people dealing with machines all week long – tend to become themselves – machines. (brain forgets how to verbal speak)

Humans != machines. Humans should have consciousness (hopefully) that allows them to realize “what is the right thing” and emotions that (hopefully) motivates them – to “do the right thing” – machines have not yet such features. (CIA investing into quantum computing, Mr Musk investing into AI development)

Without social skills – cooperation between humans declines – without cooperation mankind is fucked.

And Mr Torvalds thinks if you are NOT rude – people won’t understand you. I disagree.

Back in 2014 systemd caused a flodding of kernel.log which caused systems to not boot anymore – Torvalds was pissed.

I would say – this is placed in the area of project-management – especially software-project management.

And as you can read in my article – “how to write perfect software and finish on time” (not) you will realize – errors are not the exception – they are the rule – and rate of errors increases with complexity (amount of people, features and lines of code).

technical but also concept-errors, design errors so to speak.

so every software company and product needs:

1. simplicity – as simple as possible = easy (fast) to understand and handle/modify/fix
(this is where systemd might not be so great, thus if programs tend to become big, break it down into separate testable modules… or you will never finish the project (compiling and testing takes too much time))

2 people with time-resources and other resources (electricity) and good logic that can focus and stick to a task until it is 99% error free

3. clearly defined goals

4. some form of quality-and-error-management (use-case documentation and automated or manual testing… the boring stuff of software development :-D)

5. time

If not – they believe to be in god-mode – and forget – only nobody is perfect. But who would like to be a nobody?

what could Mr Torvalds improve in his way of communication – what we all should do – no matter how angry you are try:

1. say something positive

2. criticize

and you will be heared. completely without scandals.

back to topic:

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution. See Lennart’s blog story for a longer introduction, and the three status updates since then. Also see the Wikipedia article. If you are wondering whether systemd is for you, please have a look at this comparison of init systems by one of the creators of systemd.


future changes

systemd provides various interfaces developers and programs might rely on. Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.

The stable interfaces are:

  • The unit configuration file format. Unit files written now will stay compatible with future versions of systemd. Extensions to the file format will happen in a way that existing files remain compatible.
  • The command line interface of systemctl, loginctl, journalctl. We will make sure that scripts invoking these commands will continue to work with future versions of systemd. Note however that the output generated by these commands is generally not included in the promise, unless it is documented in the man page. Example: the output of “systemctl status” is not stable, but the one of “systemctl show” is, because the former is intended to be human readable and the latter computer readable, and this is documented in the man page.
  • The protocol spoken on the socket referred to by $NOTIFY_SOCKET, as documented in sd_notify(3).
  • Some of the “special” unit names and their semantics. To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions. To list them here:,,,,,,,,,,,, runlevel[1-5].target.
  • For a more comprehensive and authoritative list, consult the Interface Portability And Stability Chart

The following interfaces will not necessarily be kept stable for now, but we will eventually make a stability promise for these interfaces too. In the meantime we will however try to keep breakage of these interfaces at a minimum:

  • The D-Bus interfaces of the main service daemon (!) [ An additional restriction applies here: functionality we consider legacy might not be available based on compile-time options, such as SysV support, libwrap support and similar. Apps should not assume properties and methods related to this functionality are unconditionally available in the D-Bus interfaces. ]
  • The set of states of the various state machines used in systemd, e.g. the high-level unit states inactive, active, deactivating, and so on, as well (and in particular) the low-level per-unit states.
  • All “special” units that aren’t listed above.

The following interfaces are considered private to systemd, and are not and will not be covered by any stability promise:

  • Undocumented switches to systemd, systemctl and otherwise
  • The internal protocols used on the various sockets such as the sockets /run/systemd/shutdown, /run/systemd/private.

One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions. Systemd project does not contain any distribution-specific parts. Distributions are expected to convert over time their individual configurations to the systemd format, or they will need to carry and maintain patches in their package if they still decide to stay different.

What does this mean for you? When developing with systemd, don’t use any of the latter interfaces – use systemd.

You are welcome to use other interfaces, but if you use any of the second kind (i.e. those where we don’t yet make a stability promise), then make sure to subscribe to our mailing list, where we will announce API changes, and be prepared to update your program eventually.

Note that this is a promise, not an eternal guarantee. These are our intentions, but if in the future there are very good reasons to change or get rid of an interface we have listed above as stable, then we might take the liberty to do so, despite this promise. However, if we do this, then we’ll do our best to provide a smooth and reasonably long transition phase.




/bin/systemd --help

systemd [OPTIONS...]

Starts up and maintains the system or user services.

  -h --help                      Show this help
     --test                      Determine startup sequence, dump it and exit
     --no-pager                  Do not pipe output into a pager
     --dump-configuration-items  Dump understood unit configuration items
     --unit=UNIT                 Set default unit
     --system                    Run a system instance, even if PID != 1
     --user                      Run a user instance
     --dump-core[=BOOL]          Dump core on crash
     --crash-vt=NR               Change to specified VT on crash
     --crash-reboot[=BOOL]       Reboot on crash
     --crash-shell[=BOOL]        Run shell on crash
     --confirm-spawn[=BOOL]      Ask for confirmation when spawning processes
     --show-status[=BOOL]        Show status updates on the console during bootup
     --log-target=TARGET         Set log target (console, journal, kmsg, journal-or-kmsg, null)
     --log-level=LEVEL           Set log level (debug, info, notice, warning, err, crit, alert, emerg)
     --log-color[=BOOL]          Highlight important log messages
     --log-location[=BOOL]       Include code location in log messages
     --default-standard-output=  Set default standard output for services
     --default-standard-error=   Set default standard error output for services

startup speed analyzed


systemd-analyze; # analyze system startup speed
Startup finished in 1.097s (kernel) + 4.838s (initrd) + 4.832s (userspace) = 10.768s

systemd-analyze blame; # analyze system startup speed
 systemd-analyze blame
          2.521s spamassassin.service
          1.242s csf.service
           967ms tuned.service
           765ms httpd.service
           612ms rc-local.service
           587ms lvm2-monitor.service
           574ms dev-mapper-centos\x2droot.device
           505ms network.service
           469ms NetworkManager-wait-online.service
           379ms nginx.service
           318ms iptables.service
           224ms lfd.service
           184ms rsyslog.service
           143ms systemd-vconsole-setup.service
           136ms NetworkManager.service
           103ms lvm2-pvscan@8:2.service
            84ms clamd.service
            79ms sshd.service
            74ms polkit.service
            59ms home.mount
            54ms systemd-tmpfiles-setup-dev.service
            49ms kdump.service
            43ms plymouth-quit-wait.service
            43ms plymouth-quit.service
            41ms auditd.service
            39ms chronyd.service
            37ms systemd-sysctl.service
            36ms plymouth-read-write.service
            35ms dev-mqueue.mount
            35ms rhel-readonly.service
            33ms dev-hugepages.mount
            31ms systemd-udevd.service
            30ms systemd-remount-fs.service
            29ms systemd-user-sessions.service
            29ms rhel-domainname.service
            28ms rhel-dmesg.service
            28ms systemd-journal-flush.service
            27ms sys-kernel-debug.mount
            24ms systemd-journald.service
            23ms systemd-tmpfiles-clean.service
            21ms systemd-udev-trigger.service
            17ms systemd-tmpfiles-setup.service
            16ms boot.mount
            14ms plymouth-start.service
            14ms rhel-import-state.service
            13ms systemd-fsck-root.service
            13ms systemd-logind.service
            11ms kmod-static-nodes.service
             5ms systemd-update-utmp.service
             5ms dev-mapper-centos\x2dswap.swap
             3ms systemd-update-utmp-runlevel.service
             3ms systemd-random-seed.service
             1ms sys-kernel-config.mount

where is systemd?

list of files and folders involved: systemd.filelist.txt

(output of dpkg-query -L systemd, which seems to be the same as dpkg -L systemd… but anyway)

ll /sbin |grep init
lrwxrwxrwx 1 root root 20 Apr 8 23:08 init -> /lib/systemd/systemd
lrwxrwxrwx 1 root root 14 Apr 8 23:08 telinit -> /bin/systemctl

ll /lib/systemd/systemd
-rwxr-xr-x 1 root root 1.1M Jun 4 22:58 /lib/systemd/systemd

root@debian:~# stat /lib/systemd/systemd
File: ‘/lib/systemd/systemd’
Size: 1316528 Blocks: 2576 IO Block: 4096 regular file
Device: 801h/2049d Inode: 6294591 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

dpkg -l|grep systemd

ii dbus-user-session 1.10.18-1 all simple interprocess messaging system (systemd --user integration)
ii libpam-systemd:amd64 232-25 amd64 system and service manager - PAM module
ii libsystemd0:amd64 232-25 amd64 systemd utility library
ii systemd 232-25 amd64 system and service manager
ii systemd-sysv 232-25 amd64 system and service manager - SysV links


Control the systemd system and service manager.


root@debian9:~# systemctl


Useful SystemD commands (hints for systemctl or systemctl vs chkconfig and service)

List all running services


Start/stop or enable/disable services

Activates a service immediately:

systemctl start foo.service

Deactivates a service immediately:

systemctl stop foo.service

Restarts a service:

systemctl restart foo.service

Shows status of a service including whether it is running or not:

# very detailed status with last x log lines
systemctl status foo.service
# short version
# outputs only active or inactive
# warning! it also shows "inactive"
# when the service is not existing!
systemctl is-active boot.mount
systemctl is-active NonExistingService

it is scriptable:

systemctl is-active --quiet service && echo Service is running

Enables a service to be started on bootup:

systemctl enable foo.service

Disables a service to not start during bootup:

systemctl disable foo.service

Check whether a service is already enabled or not:

systemctl is-enabled foo.service; echo $?

0 indicates that it is enabled. 1 indicates that it is disabled

How do I change the runlevel?

systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.

Run level 3 is emulated by Run level 5 is emulated by is a symbolic link to and is a symbolic link to

You can switch to ‘runlevel 3′ by running

systemctl isolate
# or
systemctl isolate

You can switch to ‘runlevel 5′ by running

systemctl isolate
# or
systemctl isolate

How do I change the default runlevel?

systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first before creating a new one

rm /etc/systemd/system/

Switch to runlevel 3 by default

ln -sf /lib/systemd/system/ /etc/systemd/system/

Switch to runlevel 5 by default

ln -sf /lib/systemd/system/ /etc/systemd/system/

systemd does not use /etc/inittab file.

List the current run level

runlevel command still works with systemd. You can continue using that however runlevels is a legacy concept in systemd and is emulated via ‘targets’ and multiple targets can be active at the same time. So the equivalent in systemd terms is

systemctl list-units --type=target

Powering off the machine

You can use


Some more possibilities are: halt -p, init 0, shutdown -P now

Note that halt used to work the same as poweroff in previous Fedora releases, but systemd distinguishes between the two, so halt without parameters now does exactly what it says – it merely stops the system without turning it off.


Service vs. systemd

service NetworkManager stop

# or

systemctl stop NetworkManager.service

Chkconfig vs. systemd

chkconfig NetworkManager off

# or

systemctl disable NetworkManager.service


systemd has a built-in readahead implementation. It is not enabled on upgrades.

It should improve bootup speed but your mileage may vary depending on your hardware.

To enable it:

systemctl enable systemd-readahead-collect.service
systemctl enable systemd-readahead-replay.service
# does not work in debian9 systemd?

SystemD cheatsheet

service foobar start systemctl start foobar.service Used to start a service (not reboot persistent)
service foobar stop systemctl stop foobar.service Used to stop a service (not reboot persistent)
service foobar restart systemctl restart foobar.service Used to stop and then start a service
service foobar reload systemctl reload foobar.service When supported, reloads the config file without interrupting pending operations.
service foobar condrestart systemctl condrestart foobar.service Restarts if the service is already running.
service foobar status systemctl status foobar.service Tells whether a service is currently running.
ls /etc/rc.d/init.d/ ls /lib/systemd/system/*.service /etc/systemd/system/*.service Used to list the services that can be started or stopped
chkconfig foobar on systemctl enable foobar.service Turn the service on, for start at next boot, or other trigger.
chkconfig foobar off systemctl disable foobar.service Turn the service off for the next reboot, or any other trigger.
chkconfig foobar systemctl is-enabled foobar.service Used to check whether a service is configured to start or not in the current environment.
chkconfig foobar –list ls /etc/systemd/system/*.wants/foobar.service Used to list what levels this service is configured on or off
chkconfig foobar –add Not needed, no equivalent.


Why systemd?

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.


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


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.



/etc/systemd/journald.conf (from debian8)


liked this article?

  • only together we can create a truly free world
  • plz support dwaves to keep it up & running!
  • (yes the info on the internet is (mostly) free but beer is still not free (still have to work on that))
  • really really hate advertisement
  • contribute: whenever a solution was found, blog about it for others to find!
  • talk about, recommend & link to this blog and articles
  • thanks to all who contribute!