systemd is 10 years old, but feelings about it in the Linux community have not abated – it is as divisive as ever. Although it is used by many major Linux distributions, the hardcore opposition has not given up.
Linux boot sequence
When you turn on your computer, the hardware starts, then (depending on the type of Boot sector your computer is using) or master boot record (MBR) performs or Unified Expandable Firmware Interface (UEFI) is executed. The last action of these two is to turn on the Linux kernel.
The kernel is loaded into memory, decompresses and initializes. A temporary file system is created in RAM, usually by a utility called initramfs or initrd. This will determine and load the required drivers. This, in turn, allows the user space file system to load and prepare to establish the user space environment.
The creation of the user space environment is managed by the init process, which is the first process launched by the kernel in a user space. He has a Process ID (PID) of 1. All other processes are direct or indirect children of the init process.
Before systemd, the default for the init process was a redesign of the Unix System V init. There were other choices available, but System V init was the standard option in mostBerkeley software distribution (BSD) derivative distributions. Because it came directly from System V Unix – the spiritual ancestor of Linux – many people regard it as “the official way” of initiating.
The init process starts every demons and the services required to operate the operating system meaningfully and interactively. These daemons manage things like the networking stack, activating other hardware inside your computer, and providing a splash screen.
Many of these background processes continue to run after they start. They do things like log event information, monitor hardware changes when you insert or remove devices, and manage user connections. Unsurprisingly, the init system also includes functionality to manage services.
We can use ps to see the process that has PID 1. We will use the options f (full format list) and p (PID):
ps -fp 1
We see that the process with PID 1 is systemd. Running the same command on Manjaro Linux gave a different result. The process with PID 1 has been identified as / sbin / init. A quick glance at this file shows that it is a symbolic link to systemd:
ps -fp 1
ls -hl / sbin / init
Using the ppid (parent process ID) option with ps, we can see which processes were started directly by systemd:
ps -f –ppid 1
It’s a fairly long list, as you can see in the image below.
Several projects have attempted to produce an alternative to the traditional initial V system. One of the main problems is that, with System V init, all the processes are started in series, one after the other. To improve the efficiency of the start-up sequence, many alternative projects use parallelism to start processes simultaneously and asynchronously.
Here is some information on some of them:
Reached: Developped by Canonical, it was used in Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6, and Felt 9.
Execute: Works on FreeBSD and other BSD derivatives, macOS and Solaris, as well as Linux systems. It is also the default initialization system on None Linux.
s6-linux-init: This replacement for the V init system was designed to closely monitor the Unix philosophy, which is often reduced to the bite of the “do one thing and do it right” sound.
There are many other different features and designs. However, none of them created fury systemd did it.
The Systemd Way
systemd was released in 2010 and was used in Fedora in 2011. Since then, it has been adopted by many distributions. It was developed by Lennart Poettering and Kay Sievers, two software engineers at RedHat.
systemd is much more than an init replacement. Rather, it is a suite of about 70 binary files that handle system initialization, daemons and services, logging and logging, as well as many other functions that were already managed by dedicated modules under Linux. Most of them have nothing to do with system initialization.
Some of the daemons provided by systemd are:
systemd-udevd: Manages physical devices.
systemd-logind: Manages user connections.
solved by systemd: Provides network name resolution to local applications.
systemd-networkd: Manages and detects network devices and manages network configurations.
systemd-tmpfiles: Creates, deletes and cleans up volatile and temporary files and directories.
systemd-localed: Manages the regional settings of the system.
machined by the system: Detects and monitors virtual machines and containers.
systemd-nspawn: Can launch an command or other process in a lightweight namespace container, offering functionality similar to chroot.
And this is just the tip of the iceberg, which is also the crux of the problem. systemd has long gone beyond what is required of an init system, which, according to its opponents, is the very definition of range creep.
“It’s too big. It’s too much.”
Opponents of systemd point to the wide and curious mix of features it encompasses. All of these features already existed on Linux, and perhaps some of them needed a refresh or a new approach. However, combining all of these features into what is supposed to be an initialization system is architecturally confusing.
systemd has been called a single point of failure for too many critical functions, but this does not seem to be justifiable. Certainly it throws the Unix philosophy create small tools that work together instead of big software that does everything out the window. Although systemd is not strictly monolithic (it includes many binary files rather than a single huge one), it includes many disparate management tools and commands under one umbrella.
Although it is not monolithic, it is large. To get an idea of the scale, we counted the lines of text in the kernel code base 5.6.15 and the master systemd branch. of the GitHub repository.
It was a relatively coarse metric. It counted lines of text, not just lines of code. So that included comments, documentation, and everything in between. However, it was a comparable comparison and gave us a simple test:
(find ./ -name ‘*. *’ -print0 | xargs -0 cat) | wc -l
The kernel had nearly 28 million lines of text (27,784,340, to be exact). In contrast, systemd had 1,349,969, or nearly 1.4 million. With our happy-go-lucky metric, systemd comes out at around 5% of the kernel size, which is crazy!
As another comparison, the number of lines for a modern implementation of System V init for the Arch Linux distribution came out at 1,721 lines.
Poettering clearly has no respect for Institute of electrical and electronic engineers (IEEE) Computer Society, nor the Portable operating system interface (POSIX) standard. In fact, encouraged developers to ignore POSIX:
“So get a copy of the Linux programming interface, ignore everything it says about POSIX compatibility and hack your amazing Linux software.” It’s quite relieving! “
There have been accusations that systemd is a Red Hat project that only benefits Red Hat, but it is being force-fed into the Linux world at large. Yes, he was born in Red Hat and is governed and led by him. However, of the 1,321 contributors, only a fraction works for Red Hat.
So what are the benefits for Red Hat?
“Red Hat considered many of the options available and even used Upstart from Canonical for Red Hat Enterprise Linux 6. Ultimately, we chose systemd because it’s the best architecture that offers scalability, simplicity, scalability and well-defined interfaces to solve the problems we see. today and in the future. “
Whitehurst also said they also see benefits in embedded systems. Red Hat partners with “the world’s largest integrated suppliers, particularly in the telecommunications and automotive industries, where stability and reliability are the number one concern.”
These reasons seem technically sound. You can understand the need for business reliability, and it is not unreasonable for Red Hat to look after its own interests, but should everyone do the same?
Drinking Systemd Kool-Aid?
Some opponents of systemd claim that distributions and people blindly follow Red Hat’s example and embrace it.
However, like the phrase “drink Kool-Aid”, this is not entirely true. Invented in 1978 after cult leader, Jim Jones, forced its more than 900 followers to commit suicide by drinking a liquid flavored with grapes coated with cyanide, the phrase wrongly shame Kool-Aid. The group actually drank Flavor Aid, but Kool-Aid has been tarred by this brush ever since.
In addition, Linux distributions do not blindly follow Red Hat; they adopt systemd after serious deliberation. The debate rages on Debian mailing lists for a long time. However, in 2014, the community voted to adopt systemd as default initialization system but to also support alternatives.
Debian is an important example because it is not derived from RedHat, Fedora or CentOS. There is no control applied to Debian from Red Hat. And Debian, like PID 1, has many descendants, including Ubuntu and its many spinoffs.
The decisions made by the Debian community are far reaching. They are also hotly debated and voted on the use the Condorcet voting method. The community also does not make these choices lightly.
He voted again in December 2019 to continue to focus on systemd and continue to explore alternatives. The opposite of blindly following is actually a classic example of democracy and freedom of choice at work.
The limits of choice
Generally, you have no choice but to use systemd with a particular Linux distribution. On the contrary, the distributions themselves choose whether they want to use it, and you can choose the Linux distribution you prefer. Maybe a Linux distribution that you like is passed to systemd. As a favorite musician who changes genres, it can be shocking.
People who use Debian, Felt, CentOS, Ubuntu, Camber, Solus, and openSUSE, and opposing the adoption of systemd, might feel pressured to use their distribution of choice. If they are convinced enough by one of the architectural choices, the creep of the range or the non-respect of POSIX, they could find it untenable to continue using this distribution.
There is of course a spectrum. At one end, you have people who don’t understand the problems (or even the care), and at the other, you have passionate objectors. Somewhere in the middle are those who don’t like changes, but don’t care enough to leave the ship. But what about distribution refugees, who cannot stay on their chosen distribution because of their preferences or principles?
Unfortunately, it’s not as simple as installing the desired boot system. Not everyone has the technical ability to do this, no matter what difficulties arise when applications or desktop environments, such as GNOME, have dependencies on systemd.
What if you switch to another distribution? Some, like Devuan, appeared as non-systemd forks of distributions (in this case, Debian) that had adopted systemd. Using Devuan should be similar to the parent distribution, but not all non-systemd forks. For example, if you quit Fedora and go to AntiX, Gentoo, or Slackware, you are going to have a very different experience.
It’s not going anywhere
I like some of what systemd does (simple, standardized control mechanisms for processes). I don’t understand the reason for some of its effects (binary logs). I also don’t like what he does (reorganize the starting files– who asked for that?).
Distributions like Debian do the smart thing and look for alternatives to keep its options open. However, systemd is there for the long haul.
If you are administering Linux machines for others, learn systemd as well as you know System V init. That way, no matter what you are having, you will be able to accomplish your tasks.
Are you just using Linux at home? If so, choose a distribution that both meets your technical needs and complements your Linux ideology.