The "removing systemd" experiment
Elective Surgery
The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.
Systemd [1], an essential component in major GNU/Linux distributions today, is used for system startup/shutdown as the first process, process group control, subsystem containers, logging, hardware detection and management, and communication interfaces between processes. All these features pretty much sum up the problem: systemd interconnects a lot of services that were formerly modular and independent programs, each one separately configurable. Squeezing all of them into a distro creates dependencies that greatly increase system complexity and make it difficult to look in a single place to find problems.
For example if, during the boot process, the system just hangs at a certain point, with no usable GUI or terminal login and no visible log messages, it could be that some dependent units are just "waiting for each other" (which is, from systemd's point of view, not an error but a misconfiguration). Finding the culprit can then be difficult, especially when this happens in only one out of 100 (!) startup cases.
A lot of controversy is still flying around systemd concerning, on the con side, breaking Unix system principles of modularity and low interdependency of programs and, on the pro side, faster startup through massive parallelization, "all-in-one" system design, and possibly more flexibility.
Personally, I would like to stay out of the controversy, but after running my own tests and having brief discussions with systemd's main developer, it seems to me that systemd hasn't been well tested in "real hardware" environments, especially in conjunction with old computers with small amounts of RAM and slow media like DVDs or USB (1 … 2) flash disks, which are still accommodated in Knoppix. For virtualization and container-based systems on fast hardware, systemd is surely very useful.
You may know from last year's CeBIT presentation that I'm working on a "Knoppix for Raspberry Pi," which, on one hand, is less complicated than Intel/AMD hardware, because ARM architecture usually does not have a PCI bus system – instead using a "device tree" that defines the hard-wired addresses and I/O functions for the system – requiring less "hardware detection." On the other hand, the Pi is – for modern standards – a very lightweight system than cannot be upgraded with more RAM; it doesn't even have a SATA interface, and all data must pass through a controller with little available bandwidth. Therefore, I'd like to build a very light system for the Pi that does not inherit too many requirements. Basically, I want this simple BusyBox SysVinit configuration, with a single Bash script for startup/autoconfiguration (knoppix-autoconfig.sh)
, one for the graphical desktop (knoppix-startx.sh
), and one for shutdown (knoppix-shutdown.sh
):
# /etc/inittab for busybox init (Raspi Knoppix) ::sysinit:/etc/init.d/knoppix-autoconfig.sh ::respawn:/etc/init.d/knoppix-startx.sh ::shutdown:/etc/init.d/knoppix-shutdown.sh ttyAMA0::respawn:-/bin/bash
The last line is for the Pi2-specific serial interface, which should run a Bash shell for debugging purposes.
All commands for system startup and shutdown are included in the three scripts. Some are called one after the other (to wait for dependencies, if present), and some are parallelized in a way that is known to work well. One main goal is to reach a startup time of only a few seconds, from power-on to the ready-to-use desktop.
Unfortunately (for my purpose), the Raspberry Pi distribution of Debian now also has switched to systemd, so it will be a challenge for me either to find a way to remove the systemd conglomerate of interconnected, parallelized services during startup and use the tiny SysVinit built into BusyBox instead, while also having to solve problems with Raspbian's systemd package dependencies when attempting to remove systemd, or to build a new distro from scratch.
In this article, I look at the first approach of removing systemd – at least as a boot system, if not more – and at keeping the system bootable and working.
Systemd – A Very Short Introduction
Before blindly attempting to remove a software package, it's a good idea to have a look at its purpose and function in the computer system. For SysVinit, this was rather simple: Depending on the runlevel (0 … 6) given at the boot command line, start and stop scripts in /etc/init.d/*
are called for each installed and activated subsystem (e.g., "load kernel modules," "mount hard disks," or "start up the network"). They are numbered in the order of their calling, so if a program depends on another program, it can simply be named in chronological order after its dependency.
Systemd comprises not only the startup process (process 1, the systemd
daemon), but also other services that partly replace formerly independent programs or functions (Table 1). Whereas SysVinit has commands like telinit
, reboot
, and shutdown
/poweroff
for switching runlevels, systemd has a front end called systemctl
with many options (Table 2) and that also supersedes the symlink-based SysVinit runlevel files in /etc/init.d/*
--> /etc/rc${RUNLEVEL}.d/*
.
Table 1
Systemd Suite Components
Daemon | Description |
---|---|
|
System startup/shutdown/control (like init) |
|
Seat/session management |
|
Syslog, but different (context-based, binary logfiles) |
|
Service process communication; formerly a separate program |
|
Hardware detection, device management, and driver/module loading; formerly a separate program |
|
May replace NetworkManager; does it exist yet? |
Table 2
Controlling systemd
Command | Description |
---|---|
|
Start program |
|
End program |
|
Stop+start program or tell it to apply configuration changes |
|
Enable autostart at boot |
|
Don't start at boot |
|
Show current running state of service |
|
List [also not started] bootable services |
|
List all config files, regardless of their state |
Systemd's journald
replaces the formerly text-based logfiles in /var/log
by context-sensitive binary files, and you need journalctl
to read them. Important commands to know for debugging are shown in Table 3.
Table 3
Systemd Debugging Commands
Command | Description |
---|---|
|
See all logs (also previous boots, formerly |
|
Current boot only |
|
Kernel messages only ( |
|
Only current logs of a specific service |
The /etc/systemd/system/*
files override system defaults in /lib/systemd/system/*
. The /run/systemd/system/*
files are intermediately generated and take precedence over defaults. Systemd's startup config files (Table 4) should be managed with the Systemctl GUI (Table 5) and not edited or copied directly (which you can still do, regardless of this recommendation). Systemctl even has equivalents for the SysVinit reboot
and shutdown
commands (Table 6).
Table 4
Systemd Config Files
File Type Suffix | Content |
---|---|
|
Defines a synchronization point (like runlevels) |
|
Start or stop services and define their order (like |
|
Related to services: Defines an IPC socket for communication |
|
Configuration for systemd's own server processes |
|
Additional device file setup not handled by Udev |
|
(On demand) mount point managed by systemd |
|
A mount point that's to be auto-mounted at some point |
|
Swap partition or file handled by systemd |
|
Monitor path for changes to activate services/units |
|
Like cron/at, defines time-based events and actions |
|
Temporary file containing the system state at a certain point |
|
Part of cgroups definitions for controlling subsets of processes |
|
Created automatically; contains {D,K}-Bus information |
Table 5
Managing systemd "Units"
Command | Description |
---|---|
|
See Table 2. |
|
Show unit content. |
|
Show the parsed/interpreted version. |
|
Modify [all] UNIF files. |
|
Show unit dependencies [recursively]. |
|
Execute changes globally. |
Table 6
SysVinit Equivalents in systemctl
Command | Description |
---|---|
|
End all programs and power off |
|
Restart system |
|
Like runlevel S in SysVinit |
Even in this short introduction, you can imagine the full complexity of systemd. It is also important to know that systemd introduced its own pluggable authentication module (PAM) for session management in connection with systemd-logind
. A process can ask about the owner of the console and graphical session by sending a message to D-Bus, which is then answered by systemd-logind
, having learned about the user's login from the libpam-systemd
component.
Experiment Prerequisites
For the experiments described here, I use a popular, lightweight distro – Lubuntu (the LXDE desktop variant of Ubuntu) – in the kvm
virtualizer in order to reset everything to start after unsuccessful changes and be able to monitor everything from a working host system.
Also, because the old SysVinit packages have disappeared from the main repositories, I prepared one sysvinit.deb
containing /sbin/init
, to replace systemd. This should be installed first; otherwise, Lubuntu will complain about missing "essential system packages." The first step is always:
sudo dpkg --force-all -i sysvinit_2.88knoppix_i386.deb \ initscripts_2.88knoppix_i386.deb \ sysvinit-utils_2.88knoppix_i386.deb \ sysv-rc_2.88knoppix_all.deb
Round 1: Just Remove systemd
For the first test, I wanted to see what would happen if I just removed systemd
using the Apt standard packaging tool (Listing 1). On the plus side, this will free about 80MB of disk space …. Just kidding.
Listing 1
Removing systemd with Apt
As expected, at command completion and reboot, the system comes up with a black screen. Removing the quiet
option and adding debug
in the GRUB boot menu helps somewhat in understanding why. Part of the problem is that way too many services are just gone with systemd, because of soft dependencies set in their package metadata, which affects network configuration and most of the graphical user interface. The other part of the problem is covered in the analysis in round 2.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.
-
Juno Tab 3 Launches with Ubuntu 24.04
Anyone looking for a full-blown Linux tablet need look no further. Juno has released the Tab 3.
-
New KDE Slimbook Plasma Available for Preorder
Powered by an AMD Ryzen CPU, the latest KDE Slimbook laptop is powerful enough for local AI tasks.
-
Rhino Linux Announces Latest "Quick Update"
If you prefer your Linux distribution to be of the rolling type, Rhino Linux delivers a beautiful and reliable experience.