Systemd Vs Init for Linux Beginners (Final Verdict)

Linux TLDR
Last Updated:
Reading time: 6 minutes

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.

init vs systemd

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).

  • 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

Interfacing via D-BusNoYes
Shell-free bootupNoYes
Modular C coded early boot services includedNoYes
Socket-based ActivationNoYes
Socket-based Activation: inetd compatibilityNoYes
Bus-based ActivationNoYes
Device-based ActivationNoYes
Configuration of device dependencies with udev rulesNoYes
Path-based Activation (inotify)NoYes
Timer-based ActivationNoYes
Mount handlingNoYes
fsck handlingNoYes
Quota handlingNoYes
Automount handlingNoYes
Swap handlingNoYes
Snapshotting of system stateNoYes
Optionally kills remaining processes of users logging outNoYes
Linux Control Groups IntegrationNoYes
Audit record generation for started servicesNoYes
SELinux integrationNoYes
PAM integrationNoYes
Encrypted hard disk handling (LUKS)NoYes
SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agentsNoYes
Network Loopback device handlingNoYes
binfmt_misc handlingNoYes
System-wide locale handlingNoYes
Console and keyboard setupNoYes
Infrastructure for creating, removing, and cleaning up temporary and volatile filesNoYes
Handling for /proc/sys sysctlNoYes
Plymouth integrationNoYes
Save/restore random seedNoYes
Static loading of kernel modulesNoYes
Automatic serial console handlingNoYes
Unique Machine ID handlingNoYes
Dynamic host name and machine meta data handlingNoYes
Reliable termination of servicesNoYes
Early boot /dev/log loggingNoYes
Minimal kmsg-based syslog daemon for embedded useNoYes
Respawning on service crash without losing connectivityNoYes
Gapless service upgradesNoYes
Graphical UINoYes
Built-in profiling and toolsNoYes
Instantiated servicesNoYes
PolicyKit integrationNoYes
Remote access/Cluster support built into client toolsNoYes
Can list all processes of a serviceNoYes
Can identify service of a processNoYes
Automatic per-service CPU cgroups to even out CPU usage between themNoYes
Automatic per-user cgroupsNoYes
SysV compatibilityYesYes
SysV services are controllable like native servicesYesYes
SysV-compatible /dev/initctlYesYes
Re-execution with full serialization of stateYesYes
Interactive boot-upNoYes
Container support (as an advanced chroot() replacement)NoYes
Dependency-based bootupNoYes
Disabling services without editing filesYesYes
Masking of services without editing filesNoYes
Robust system shutdown within PID 1NoYes
Built-in kexec supportNoYes
Dynamic service generationNoYes
Upstream support for various other OS componentsYesYes
Service files compatible between distributionsNoYes
Signal delivery to servicesNoYes
Reliable termination of user sessions before shutdownNoYes
utmp/wtmp supportYesYes
Easily writable, extensible, and parseable service files, suitable for manipulation with enterprise management toolsNoYes

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.

Join The Conversation

Users are always welcome to leave comments about the articles, whether they are questions, comments, constructive criticism, old information, or notices of typos. Please keep in mind that all comments are moderated according to our comment policy.

7 thoughts on “Systemd Vs Init for Linux Beginners (Final Verdict)”

  1. 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.

  2. This article was interesting, but one major controversy at the time was forgotten
    – the init is a critical system. SystemV is well tested, and systemd is too new to replace it by default. (morever as this article point it : other solutions already existed before, and were already largely deployed like openrc and upstart… )
    – In addition, shell script could easily be modified in-situ if the necessity comes. Systemd as a binary suite doesn’t offer this.

    And, as I needed to work on a solution from rhel6 to rhel7, theses concerns were justified. On the first rhel7, systemd will just stop to boot one boot every 30. And even on the lasts rhel7 , systemd doesn’t manage to shutdown correctly in degraded condition (as nfs server out, or when a unit doesn’t stop well or cryptswap)

  3. Please stop spelling systemd wrong. It’s a daemon and spelled like any other ones. systemd, httpd, dhcpcd, klogd, sndiod.