Retired Techie
Getting older, not necessarily wiser!
SystemD Leviathan Part 1: Overview
Published on October 4, 2023 at 1:02 pm by LEWIntroduction
In this series of articles I will be looking at systemd. I don’t really want to call it the systemd init system, as that is only part of its overall functionality.
Hence the use of the term Leviathan, as it is large, with lots of tentacles (maybe kraken would have been a better metaphor) reaching into many different aspects of the operating system.
While not being a fan boy, I also do see a few postive aspects to what it does and what it has provided. As a matter of fact, and for the record, I find myself somewhat ambivalent about the whole subject. Yes there are some issues with systemd, but by the same token there are good things about it also.
One of my purposes for writing this series is to help introduce myself, as well as others, to the things systemd can do for us. For this series I plan to make a concerted effort to test every systemd subsystem, while documenting my experiences.
However that is for later posts. In this first section I want to take a high level view of systemd, and my current impressions of it.
The Init System
Before jumping into systemd, we need to understand how Operating Systems (OS) systems boot. The term “init” is short for initialization. It is the first program/process that is run during startup of Unix/Linux like systems. And it continues to run until system shutdown. The init program is a daemon (a program that is constantly running in the background).
Then init process (a process is one of many instances of a programs running on a multi threaded/multitasking OS) is the parent (direct or indirect) of all other processes that are or will be running between boot and shutdown.
There have been several different implementations (and variations) of init over the years. A few of them are; SystemIII, SystemV, launchd, Runit, OpenRC, and systemd.
Short History of systemd
Lennart Poettering and Kay Sievers started developing systemd in 2010 as a replacement for SystemV, for Red Hat Linux. They had several goals for the new software; increase efficiency of the intit process, reduce overhead, and improve parallel processing during boot.
In 2011 systemd became the default init process in Fedora Linux (non commercial version of Red Hat).
In 2012 Arch Linux switched to systemd. In 2014 Debian Linux also switched to systemd. Currently most major Linux distributions use systemd as the default init process.
My Thouughts
Say what you want about systemd, it has forced a certain level of standardization of the boot process and service handling among many divergent Linux Distributions (something that was sorely needed).
Generally speaking, service scripts in systemd are easier for me to understand, modify, and customize as compared to the SystemV scripts I have worked with. And yes I know some people might object to the term “script” as used here
Process monitoring/control in systemd, though the journaling system is much better than it ever was in other init systems. For example, in SystemV I could query if a service was running, and that is what I would get back, whether it is running or not. Systemd provides much more detailed information when queried.
I would use the word scope creep to describe the continuing efforts to make everything reliant on systemd. I have watched more and more functionality being added to systemd. Normally this would be a good thing, except that systemd is somewhat monolithic. Thus installing systemd as the inti process also installs other functionality that duplicates other programs, and may or may not be what the end user wants.
A large number of additional redundant services are part of the systemd system. This would not be bad if systemd was modular. But it is not, so you end up with a rather large interface on process 1, which can introduce vulnerabilities to your system (search the internet for systemd and privilege escalation for an example of this).
Even though systemd is open source, its main sponsor is Red hat Linux (a corporation). I give credit to Red Hat for making it open source. But Red Hat is still a corporation, and I have been in enough corporate meetings to know things can change in an instant if enough dollar signs are seen (look at what Canonical has been doing for example).
A summary of the first point of the Unix philosophy is “do one thing well”. This was obviously ignored by the systemd developers, as it appears to try to do everything.
What This Means for the Average user
All of the above probably means next to nothing for the average user who just wants there system to work. Systemd works, even though it failed at one of its objectives, with all the added components, systemd is no longer as efficient as its predecessors, and takes longer to boot. This is not much of an issue on modern hardware.
The biggest issue that regular users should worry about is being hacked, as unlikely as this might be. Because systemd tries to do many things in addition to handling services, it has a rather large exposed interface, meaning it is more susceptible to exploits being found.
Conclusion
Because of the prevalence of systemd, I would suggest not trying to avoid it. It does the job it needs to do and it works. It is also a standard in most Linux distributions today.
For the distribution developers and maintainers, I do have a few suggestions. Keep an eye on anything coming from or sponsored by a corporation/business. You are always just a meeting away form being closed out of something you are using regularly, like systemd. Some of Red hats latest moves make me wonder if things are heading in that direction.
I would also suggest all non business non profit sponsored distributions that rely on systemd get together and start looking at developing their own alternative. Maybe systemdm (m for modular). Because any new incarnation should have only the init process as its core, and everything else should be a module the user can add if they need or want it.
But, unless Red Hat pulls a real boneheaded move, systemd is here for the foreseeable future, so we might as well learn about its capabilities and how to use them.
In the next installment, I will be looking at an overview of systemd services, and exploring the systemctl command.
SystemD Leviathan Part 1: Overview
SystemD Leviathan Part 2: Service Units
SystemD Leviathan Part 3: Time Works
Add New Comment