Systemd Vs Init for Linux Beginners (Final Verdict)

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: is another lightweight init system that provides basic initialization functions for the Linux system.
• OpenRC: is 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: is 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).

• Check If You Are Using SystemD or Not in Linux

• 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”.
• The goodness of providing multiple things in one place is also the reason for its criticism of increasing the attack surface for hackers.
• 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

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.