Controversy of ‘init’ and ‘systemd’ in Linux

Linux TLDR
Last Updated:
Reading time: 5 minutes

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

Also Read: 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 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

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

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.

4 thoughts on “Controversy of ‘init’ and ‘systemd’ in Linux”

  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.