The ‘init’ vs ‘systemd’ is a serious debate topic that divides the Linux user into two groups. 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.
So, to begin with, we will go through the following steps to make it easier for beginners to understand how this got started and what the situation is right now.
- 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?
The init (short for “initialization”) is the first (or parent) process loaded by your kernel that swamps other (child) processes to make your system work in a systematic manner, and it is assigned with “PID=1” (process identifiers are assigned in sequential order).
As this is the parent of all processes, it has the responsibility to keep running until the user sends a halt signal; otherwise, you might experience the stage called “Kernel Panic”.
When you hear the term “init” in conjunction with it, you will also hear the term “System V init”, 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 for now I’ll focus on one major: “Do one thing and do it well”. This referred to the init behavior of starting one process after the previous one had completed in serial.
Init Alternatives Before SystemD?
Now, before SystemD takes the spotlight, I’d like to mention that when the init system was first introduced, there were a few things lacking, and the developer thought that it should be replaced with something more perfect.
With that thought, many alternatives were developed over time, followed by:
- Runit: A lightweight version of init that utilizes the “/etc/runit/*“.
- Sysmaster: Another lightweight version of init.
- OpenRC: It’s not the replacement of init but can be considered an addon or extension that allows for parallel processing on system boot.
- Initng: A init replacement daemon was implemented that allowed processes to start in parallel once their dependencies were satisfied. In its beta phases, many systems like Pingwinek, Enlisy, Berry Linux, and Bee choose it as the default init system.
- Upstart: A init replacement daemon that was developed by Canonical to allow parallel processing.
- Epoch: A single threaded init system designed to be small and unintrusive.
- SystemD: A init replacement daemon with parallelization capabilities and starts from the configuration files rather than shell script like they are in the init system.
What is SystemD?
SystemD (where “D” refers to Linux daemon) is very similar to init in terms of initialization; where it starts with your system as the parent process for all of your child processes with “PID=1”.
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.
Apart from that, systemd provides the systemctl command-line tool to manage your system services (also referred to as “daemons” or “systemd units“) to help you with common system administrator tasks.
What Init Lacked?
Although it was a fantastic daemon, a major drawback was its lack of support for parallel processes during system boot. It is important to note that it was never designed with the intention of increasing boot speed.
Another factor contributing to init’s lack of functionality is that, in contrast to systemd configuration files, it uses shell scripts to start various system functions that are under the control of “superscript”.
The positive thing about this approach was that the script was in editable text files (if you are a root user), you could see exactly what the script was trying to do, and it also supported the standard (syslog) text logging method.
Over time, as the system became more modern, the script got heavier, more complex, and harder to understand, and the init also did not have a direct method of representing dependencies (reference).
What does SystemD have to Offer?
When SystemD came out in 2010, it was the only suite of utility programs that had aggressive parallelization capabilities during system boot as well as central management for processes, daemons, services, and mount points.
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 support.
- Controlling running services.
- Event logging with Journald.
- Automatically restart the crashed services.
- Mount and automount points for maintenance.
- Track processes using Linux control groups.
- Give sockets and the system bus (D-Bus) access at the same time. This will cut down on the time that services have to wait.
- Dynamically control the services (or daemons) based on hardware changes.
- Job scheduling with calendar timers controlled by the systemd.
- User’s logins are managed by systemd-logind.
- On-demand services start that indirectly optimize the battery.
Linux Distribution Shipped with SystemD
The following is a list of Linux distributions that ship with SystemD, listed by the date they were released as defaults (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 2015)
- Ubuntu (year 2015)
- Linux Mint (year 2018)
Why is this replacement so debatable?
There are many reasons why this is such a controversial topic, but I’ll list them in points, followed by:
- SystemD is said to be a daemon that wants to control every process and application on the distro.
- SystemD violates the “do one thing and do it well” principle.
- Bloated systems and system maintenance are much more complex.
- The “Lennart Poettering” developer of systemd went to work with Microsoft after one year.
- The command line tool to manage systemd is very long.
The question that comes to your 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 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 have not been with Linux since its inception, you may not be concerned about this battle or controversy.
As you already might be using systemd without being aware, this topic mostly affects mature Linux users or users who are very sensitive to open-source, bloated systems, and the Linux philosophy.
For my opinion, I personally suggest to not have any good or bad in your mind between both this system as they both are great in their place and many newcomers after them.
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.