Systemd vs. init is a serious topic that sparks fire in veteran Linux users. While reading this article, many Linux users might be offended or supportive, so do not rant over me. The comment section is all for your constructive opinion.
To start, we’ll discuss this in the following way, simplifying how it began and its current status for beginners’ comprehension.
- What is (System V) Init?
- Init Alternatives Before SystemD?
- What is SystemD?
- What Init Lacked?
- What does SystemD have to Offer?
- Linux Distribution Shipped with SystemD
- Why is this replacement so debatable?
- SystemD vs Init
- Does This Controversy Matters to You?
So, let’s start with the…
What is (System V) Init?
Init (short for “initialization”) is the first (and parent) process loaded by your kernel that swamps other (child) processes to make your system work in a systematic manner, and it is assigned PID=1 (process identifiers are assigned in sequential order).
As the parent of all processes, its responsibility is to persistently operate until a halt signal is issued by the user. When it occurs, you may encounter the critical stage known as “Kernel Panic”.
When you hear the term “init” in conjunction with it, you will also hear the term “System V init” (not Systemd), which is essentially the first commercial system designed based on init, which many future Linux distributions adopted (until Systemd came).
The init is respected for many things, but I’ll currently emphasize a key aspect: its commitment to “Do one thing and do it well”. Which involves starting one process only after the previous one has been completed in serial.
Init Alternatives Before SystemD?
Before SystemD takes center stage, it’s worth noting that when the init system was initially introduced, its shortcomings led the developer to envision a more perfect replacement.
With that notion, many alternatives were progressively developed, leading to:
- Runit: A lightweight init system that uses configuration files located in “
/etc/runit/*” to manage system services. - Sysmaster: Another lightweight init system that provides basic initialization functions for the Linux system.
- OpenRC: Not a direct init system replacement but rather an extension that enables parallel processing during system boot. It enhances the capabilities of the existing init system.
- Initng: An init replacement daemon that facilitates parallel process startup once their dependencies are met. During its beta phases, it was adopted as the default init system by several systems such as Pingwinek, Enlisy, Berry Linux, and Bee.
- Upstart: An init replacement daemon developed by Canonical, designed to support parallel processing during system boot.
- Epoch: A single-threaded init system intentionally designed to be minimalistic and non-intrusive.
- SystemD: An init replacement daemon known for its powerful parallelization capabilities. It initiates services based on configuration files rather than using shell scripts as seen in traditional init systems.
What is SystemD?
SystemD is a system and service manager for Linux operating systems. It is a crucial component of most modern Linux distributions, including popular ones like Ubuntu, Fedora, CentOS, and Debian.
SystemD serves as an init system, which means it is responsible for initializing the user space and managing system services during the boot process.
The most notable feature of systemd was its parallelization capabilities and dependency-based service control logic, which allowed your system to start multiple processes in parallel, indirectly improving the boot time.
Systemd is frequently misunderstood as a daemon, but it’s actually a software suite for Linux. It offers systemctl, a command-line tool to manage system services, often referred to as “daemons” or “systemd units“, to help you with common system administrator tasks.
What Init Lacked?
While this daemon was excellent, its major drawback was its lack of support for parallel processes during system boot, as it was never designed with the intention of increasing boot speed.
Another factor for init replacement’s was its lack of functionality; unlike systemd configuration files, it relied on shell scripts to manage crucial system functions under a “superscript” control.
This approach had a positive aspect: it allowed for editable text files (for root users), offered transparency into the script’s actions, and supported the standard (syslog) text logging method.
Over time, as the system became more modern, the script grew in size and complexity, making it harder to understand, and the init also did not have a direct method of representing dependencies (reference).
What does SystemD have to Offer?
In 2010, SystemD introduced groundbreaking parallelization during system boot and centralized management for processes, daemons, services, and mount points, setting it apart as the sole utility suite with such capabilities.
SystemD also introduces the concept of units to manage various services in your system, such as a service unit, mount unit, socket unit, slice unit, and so on, where units are referred to as configuration files.
The following is a list of notable SystemD features:
- Simple, fast, and efficient boot-up.
- Mount handling.
- Snapshot functionality.
- Controlling running services.
- Event logging with Journald.
- Automatically restart the crashed services.
- Mount and automount points for maintenance.
- Process tracking via Linux control groups.
- Simultaneous socket and D-Bus access for faster service startup.
- Dynamically control the services (or daemons) based on hardware changes.
- Job scheduling with calendar timers controlled by the systemd.
- User login management with systemd-logind.
- On-demand service activation for improved battery optimization.
Linux Distribution Shipped with SystemD
Here’s a chronological list of SystemD-enabled Linux distributions, sorted by their default release dates (reference).
- Fedora Linux (year 2011)
- Mageia (year 2012)
- openSUSE (year 2012)
- Arch Linux (year 2012)
- CoreOS (year 2013)
- Manjaro Linux (year 2013)
- Red Hat (year 2014)
- CentOS (year 2014)
- Debian (year 2014)
- Ubuntu (year 2015)
- Clear Linux (year 2017)
- Linux Mint (year 2018)
Why is this replacement so debatable?
Numerous factors contribute to the controversial nature of this topic. To provide clarity, I will outline these reasons in bullet points, followed by:
- SystemD, often described as a controlling daemon for the entire distro, places everything under one parent process; failure could result in a catastrophic loss.
- It was also criticized for being complex, monolithic, and deviating from the Unix philosophy of “do one thing and do it well.
- System complexity significantly increases due to bloated systems and maintenance requirements.
- After just one year, Lennart Poettering, the developer of systemd, joined Microsoft.
- The systemd management command-line tool is quite extensive in length.
The question that comes to mind is why it was chosen over the standard init. For that reason, the systemd features section in this article highlights all the major points, but you can read the original announcement, including this post, for more descriptive information.
Although I’ve provided you with a general feature comparison between these two daemons,
SystemD vs. Init
| Features | init | systemd |
|---|---|---|
| Interfacing via D-Bus | No | Yes |
| Shell-free bootup | No | Yes |
| Modular C coded early boot services included | No | Yes |
| Read-Ahead | No | Yes |
| Socket-based Activation | No | Yes |
| Socket-based Activation: inetd compatibility | No | Yes |
| Bus-based Activation | No | Yes |
| Device-based Activation | No | Yes |
| Configuration of device dependencies with udev rules | No | Yes |
| Path-based Activation (inotify) | No | Yes |
| Timer-based Activation | No | Yes |
| Mount handling | No | Yes |
| fsck handling | No | Yes |
| Quota handling | No | Yes |
| Automount handling | No | Yes |
| Swap handling | No | Yes |
| Snapshotting of system state | No | Yes |
| XDG_RUNTIME_DIR Support | No | Yes |
| Optionally kills remaining processes of users logging out | No | Yes |
| Linux Control Groups Integration | No | Yes |
| Audit record generation for started services | No | Yes |
| SELinux integration | No | Yes |
| PAM integration | No | Yes |
| Encrypted hard disk handling (LUKS) | No | Yes |
| SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents | No | Yes |
| Network Loopback device handling | No | Yes |
| binfmt_misc handling | No | Yes |
| System-wide locale handling | No | Yes |
| Console and keyboard setup | No | Yes |
| Infrastructure for creating, removing, and cleaning up temporary and volatile files | No | Yes |
| Handling for /proc/sys sysctl | No | Yes |
| Plymouth integration | No | Yes |
| Save/restore random seed | No | Yes |
| Static loading of kernel modules | No | Yes |
| Automatic serial console handling | No | Yes |
| Unique Machine ID handling | No | Yes |
| Dynamic host name and machine meta data handling | No | Yes |
| Reliable termination of services | No | Yes |
| Early boot /dev/log logging | No | Yes |
| Minimal kmsg-based syslog daemon for embedded use | No | Yes |
| Respawning on service crash without losing connectivity | No | Yes |
| Gapless service upgrades | No | Yes |
| Graphical UI | No | Yes |
| Built-in profiling and tools | No | Yes |
| Instantiated services | No | Yes |
| PolicyKit integration | No | Yes |
| Remote access/Cluster support built into client tools | No | Yes |
| Can list all processes of a service | No | Yes |
| Can identify service of a process | No | Yes |
| Automatic per-service CPU cgroups to even out CPU usage between them | No | Yes |
| Automatic per-user cgroups | No | Yes |
| SysV compatibility | Yes | Yes |
| SysV services are controllable like native services | Yes | Yes |
| SysV-compatible /dev/initctl | Yes | Yes |
| Re-execution with full serialization of state | Yes | Yes |
| Interactive boot-up | No | Yes |
| Container support (as an advanced chroot() replacement) | No | Yes |
| Dependency-based bootup | No | Yes |
| Disabling services without editing files | Yes | Yes |
| Masking of services without editing files | No | Yes |
| Robust system shutdown within PID 1 | No | Yes |
| Built-in kexec support | No | Yes |
| Dynamic service generation | No | Yes |
| Upstream support for various other OS components | Yes | Yes |
| Service files compatible between distributions | No | Yes |
| Signal delivery to services | No | Yes |
| Reliable termination of user sessions before shutdown | No | Yes |
| utmp/wtmp support | Yes | Yes |
| Easily writable, extensible, and parseable service files, suitable for manipulation with enterprise management tools | No | Yes |
Does This Controversy Matters to You?
This section is primarily for newcomers to Linux; if you haven’t been with Linux since its inception, this battle or controversy may not concern you.
As you may already be utilizing systemd unknowingly, this subject primarily triggers experienced Linux users or individuals who place a high value on open-source principles, lean systems, and the essence of Linux philosophy.
In my view, I strongly recommend avoiding any bias or judgment between these two systems, as both have their merits and are great in their respective domains.
As a security researcher, my personal motto is to try everything, whether everyone supports it or not, and choose the one best suited to me.
So, here we will end this controversy (oops, article). If you have any questions or queries related to this topic, feel free to ask them in the comment section.
why compare sysvinit with systemD?
why don’t you reffer to dinit and 66 suite(works with s6 and runit) that are complete sollutions compared to systemD ?
Hi rhtoras,
The title mentions the comparison, but it’s more of a quick note for users who just transitioned from Windows to a Linux system, as these terms are mostly used in the Linux core community. And thanks for alerting Dinit and Suite 66 to this, as the articles are now on their way.
And your table is inaccurate. The auto mounter/autofs IS and has been supported by init for a VERY long time.
Not before the systemd was introduced, as this table represents the features at the time when the systemd was adopted by many distributions.