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.”
update: systemd blanks NetFlix X-D
security problems: non-root to root escalation: https://www.heise.de/security/meldung/System-Down-Drei-Uralt-Luecken-in-Systemd-vereinfachen-Linux-Angriffe-4270673.html
hostnamectl 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 email@example.com, and it runs only when firstname.lastname@example.org 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 default.target enabled multi-user.target enabled remote-fs.target enabled runlevel2.target enabled runlevel3.target enabled runlevel4.target enabled
service resource usage:
systemd-cgtop – what service is using how much hardware resources cpu tasks memory:
systemctl status; # output process tree hostname 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.slice │ └─user-0.slice │ ├─session-c1.scope │ │ ├─4417 su - root │ │ ├─4431 -bash │ │ ├─5879 systemctl status │ │ └─5880 less │ └─session-1.scope │ ├─2755 login -- root │ ├─3068 -bash └─system.slice ├─irqbalance.service │ └─1952 /usr/sbin/irqbalance --foreground ├─systemd-udevd.service │ └─1690 /usr/lib/systemd/systemd-udevd ├─nginx.service │ ├─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 ... 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
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.
One of systemd’s main goals is to unify basic Linux configurations and service behaviors across all distributions.
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.”
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.
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.
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)
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
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.
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: basic.target, shutdown.target, sockets.target, network.target, getty.target, graphical.target, multi-user.target, rescue.target, emergency.target, poweroff.target, reboot.target, halt.target, 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.
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 active
systemctl is-active NonExistingService inactive
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 multi-user.target. Run level 5 is emulated by graphical.target. runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target.
You can switch to ‘runlevel 3′ by running
systemctl isolate multi-user.target # or systemctl isolate runlevel3.target
You can switch to ‘runlevel 5′ by running
systemctl isolate graphical.target # or systemctl isolate runlevel5.target
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
Switch to runlevel 3 by default
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Switch to runlevel 5 by default
ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
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
systemctl stop NetworkManager.service
Chkconfig vs. systemd
chkconfig NetworkManager off
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?
|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.|
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.
|Interfacing via D-Bus||no||yes||yes|
|Modular C coded early boot services included||no||no||yes|
|Socket-based Activation: inetd compatibility||no||no||yes|
|Configuration of device dependencies with udev rules||no||no||yes|
|Path-based Activation (inotify)||no||no||yes|
|Snapshotting of system state||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|
|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|
|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|
|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|
|Built-In Profiling and Tools||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 services controllable like native services||yes||no||yes|
|Reexecution with full serialization of state||yes||no||yes|
|Container support (as advanced chroot() replacement)||no||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|
|Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools||no||no||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.
Available Native Service Settings
|Root Directory (chroot())||no||yes||yes|
|Environment Variables from external file||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|
|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|
 Upstart supports only the deprecated oom_score_adj mechanism, not the current oom_adj logic.
 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.
|Maturity||> 15 years||6 years||1 year|
|Specialized professional consulting and engineering services available||no||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.