Systemd is the mother of all processes, responsible for starting Linux hosts up to a state where they can do productive tasks.

Systemd (yes, all lower case, even at the beginning of a sentence), is a modern alternative to init and SystemV initialization scripts. And there’s more.

When I think about init and SystemV initialization, like most system administrators, I think about Linux startup and shutdown, not really managing services, such as after they’re up and running. Like init, Systemd is the mother of all processes, responsible for getting the Linux host up to a state where it can do productive tasks. Systemd is set up to do much more than the older initializers, managing many aspects of a running Linux host, including mounting file systems, managing hardware, processing timers, and system services needed to start and manage a productive host.

This series of articles, based on excerpts from my three-part Linux training course, “Using and Managing Linux: Learning System Administration from Scratch,” explores what Systemd can do when it starts up and when it’s done.

Linux boot

The full boot process of a Linux host from shutdown to run is complex, but it is open and knowable. Before going into detail, I’ll briefly walk you through the process from the time the host hardware is powered on to the time the system is ready for user login. Most of the time, the “bootstrap process” is discussed as a whole, but this is not accurate. In fact, the complete boot and startup process consists of three main parts:

  • Hardware boot: Initializes the system hardware
  • Linux guideboot: Loads the Linux kernel and Systemd
  • Linux Start thestartup: systemd prepares the host for productive work

The Linux startup phase begins after the kernel loads init or Systemd (depending on whether the distribution is using the old or new method). The init and Systemd programs start and manage all other processes, and are called the “mother of all processes” on their own systems.

It is important to distinguish hardware booting from Linux booting and Linux booting, and to clearly define the cut-off point between them. Understanding their differences and the role each plays in getting a Linux system into production allows you to manage these processes and better identify what most people call “boot” problems.

The boot process follows a three-step boot process to get the Linux machine ready for production. The boot phase begins when the kernel transfers control of the host to Systemd.

The battle for systemd

Systemd has caused widespread controversy among system administrators and others responsible for keeping Linux operating properly. On many Linux systems, Systemd takes over a lot of the tasks, causing opposition and discord among some developers and the Sysadmins community.

SystemV and Systemd are two different ways to perform the Linux boot process. SystemV startup scripts and init programs are the old methods, while Systemd using target targets is the new method. While most modern Linux distributions use the newer Systemd for startup, shutdown, and process management, there are still some distributions that don’t. One reason is that some distribution maintainers and system administrators prefer the old SystemV approach to the new Systemd.

I think both have their advantages.

Why do I prefer SystemV

I prefer SystemV because it’s more open. Use the Bash script to complete the boot. After the kernel starts the init program (which is a compiled binary), init starts the rC.sysinit script, which performs many system initialization tasks. After rc.sysinit is executed, init starts the /etc/rc.d/rc script, which in turn starts the various services defined by the SystemV startup script in /etc/rc.d/rx.d. Where X is the runlevel number to be started.

With the exception of the init program itself, all of these programs are open and easy-to-understand scripts. It’s possible to read through these scripts and know exactly what’s going on during startup, but I don’t think too many system administrators really do that. Each startup script is numbered to start the expected services in a particular order. Services are started serially and only one service can be started at a time.

Systemd, developed by Lennart Poettering and Kay Sievers at Red Hat, is a complex system of large, compiled binary executables that cannot be understood without access to the source code. It is open source, so “access to its source” is not difficult, just inconvenient. Systemd seems to represent a major refutation of several tenets of the Linux philosophy. As a binary file, Systemd cannot be opened directly for system administrators to view or make simple changes. Systemd tries to do everything, such as manage running services, while providing significantly more status information than SystemV. It also manages hardware, processes, process groups, file system mounts, and so on. Systemd is involved in almost every aspect of modern Linux hosts, making it a one-stop tool for system administration. All of this is a clear violation of the principle that programs should be small and that each program should only do one thing and do it well.

Why do I prefer Systemd

I prefer systemd as a startup mechanism because it starts as many services as possible in parallel, depending on the startup phase. This speeds up the overall startup speed and allows the host system to reach the login screen faster than SystemV.

Systemd manages almost every aspect of a running Linux system. It can manage running services while providing much more state information than SystemV. It also manages hardware, processes and process groups, file system mounts, and so on. Systemd dabbles in almost every aspect of modern Linux operating systems, making it a one-stop tool for system administration. (Sound familiar?)

The systemd utility is a compiled binary, but the toolkit is open because all configuration files are ASCII text files. The startup configuration can be modified through various GUIS and command-line tools, and various configuration files can be added or modified to meet the needs of a particular local computing environment.

The real problem

Do you think I can’t like both boot systems? I can. I’ll use either one of them.

I think the real problem and root cause of most disputes between SystemV and SystemD is that there is no choice at the system administration level. The choice of whether to use SystemV or Systemd has been made (but for good reason) by developers, maintainers, and packers of various distributions. Because init is extremely intrusive, digging up and replacing the init system has a lot of consequences that are hard to resolve outside of the distribution design process.

Although the choice was really made for me, whether my Linux host turned on and worked was my primary concern. As an end user, or even a system administrator, my main concern is whether I can get my work done, such as writing my book and this article, installing updates, and writing scripts to automate everything. As long as I can do my job, I don’t really care about the boot system used in distributions.

I care when there is a problem with startup or service management. No matter what boot system is used on the host, I know enough to find faults and fix them along the sequence of events.

Replace SystemV

There have been previous attempts to replace SystemV with something more modern. For about two versions, Fedora used something called Upstart to replace the aging SystemV, but it didn’t replace init or offer any of the changes I noticed. Since Upstart did not make any significant changes to SystemV’s problems, efforts in this direction were soon abandoned in favor of Systemd.

While most Linux developers agree that replacing the old SystemV boot system is a good idea, many developers and system administrators don’t like Systemd. Instead of revisiting all the alleged problems people have or have had with Systemd, let’s take you to two good articles that, while somewhat dated, cover most of the ground. Linus Torvalds, the creator of the Linux kernel, did not seem interested in Systemd. In a 2014 ZDNet article, “Linus Torvalds and Others On Systemd on Linux,” Linus made his feelings clear.

“I actually don’t have any particularly strong opinions about Systemd itself. I have a few issues with some of the core developers, I think they’re too flippant about errors and compatibility, and I think some of the design details are crazy (for example, I don’t like binary logging), but it’s a detail, not a big deal.”

If you don’t know Linus very well, he’s very vocal when he doesn’t like something, very clear, and very clear about not liking it. His way of dealing with his grievances has become more socially acceptable.

In 2013, Poettering wrote a lengthy blog post in which he debunked the systemD myths and delve into some of the reasons why systemD was created. This is a good read, and I highly recommend it.

Systemd task

Depending on the options used during compilation (not covered in this series), Systemd can have up to 69 binary executables to perform the following tasks, including:

  • systemdThe program runs in process PID 1 and provides the system startup capability to start as many services as possible in parallel, which additionally speeds up the overall startup time. It also manages the shutdown sequence.
  • systemctlThe program provides a user interface for service management.
  • Support for SystemV and LSB startup scripts for backward compatibility.
  • Service management and reporting provides more service status data than SystemV.
  • Provides basic system configuration tools, such as host name, date, locale, list of logged in users, running containers and VMS, system accounts, runtime directories and Settings, daemons for simple network configuration, network time synchronization, log forwarding, and name resolution.
  • Provides socket management.
  • Systemd timers provide cron-like advanced functionality, including running scripts at a point in time relative to system startup, systemd startup time, and the time the timer was last started.
  • It provides a tool to analyze dates and times used in timer specifications.
  • Layer-aware file system mount and unmount functions can cascade mounted file systems more securely.
  • Allows active creation and management of temporary files, including deletion.
  • D-bus’s interface provides the ability to run scripts when inserting or removing devices. This allows all devices (pluggable or not) to be treated as plug-and-play, greatly simplifying device processing.
  • Tools that analyze startup can be used to find the services that take the most time.
  • It includes tools for storing logs of system messages and managing logs.

architecture

These and more tasks are supported through a number of daemons, controllers, and configuration files. Figure 1 shows many of the components that belong to Systemd. This is a simplified diagram intended to provide an overview, so it does not include all individual programs or files. Nor does it provide a perspective on data flow, which is so complex that it is useless in the context of this series of articles.

systemd architecture

Figure 1: Architecture of Systemd BY Shmuel Csaba Otto Traian (CC BY-SA 3.0)

A book is needed to fully explain Systemd. You don’t need to understand the details of how the Systemd components in Figure 1 are put together. You only need to know the programs and components that support various Linux service management and log file and log processing. But it is clear that Systemd is not the monolithic monster that some critics have claimed.

Systemd as process 1

Systemd is process 1 (PID 1). Some of its features, much more extensive than the older SystemV3 Init, are used to manage many aspects of running Linux hosts, including mounting file systems and system services needed to start and manage Linux production hosts. Any Systemd tasks that are not related to the startup phase are beyond the scope of this article (but some of them will be covered in later articles in this series).

First, Systemd mounts the file system defined in /etc/fstab, including any swap files or partitions. At this point, it can access configuration files in /etc, including its own. It USES its configuration link/etc/systemd/system/default. The target to determine which will lead to the host state or goal. The default.target file is a symbolic link to the actual target file. For desktop workstations, it is usually graphical. Target, which is equivalent to run level 5 in SystemV. For servers, the default is more likely to be multi-user.target, equivalent to run level 3 in SystemV. Emergency. target is similar to single-user mode. Target and service are the unit of Systemd.

The following table (Figure 2) compares the SystemD target with the old SystemV startup run level. Systemd provides the Systemd target alias for backward compatibility. Target aliases allow scripts (and many system administrators) to change the runlevel using SystemV commands such as init 3. Of course, SystemV commands are forwarded to Systemd for interpretation and execution.

Systemd target SystemV Run level Target alias describe
default.target The target is always made by a symbolic linkmulti-user.target 或 graphical.targetThe alias. Systemd is always useddefault.targetTo boot the system.default.targetShould never be set tohalt.target.poweroff.target 或 reboot.targetThe alias.
graphic.target 5 runlevel5.target With a GUImulti-user.target.
4 runlevel4.target Unused. Run level 4 is the same as run Level 3 in SystemV. You can create and customize this target to start the local service without changing the defaultmulti-user.target.
multi-user.target 3 runlevel3.target All services are running, but only the command line interface (CLI).
2 runlevel2.target Multi-user, no NFS, and all other non-GUI services running.
rescue.target 1 runlevel1.target The base system, which includes mounting the file system, running the most basic services, and a recovery shell for the main console.
emergency.target S Single user mode: No services are running. The file system is not mounted. This is the most basic level of work, with only an emergency Shell running on the main console for the user to interact with the system.
halt.target Stop the system without turning off power.
reboot.target 6 runlevel6.target Restart.
poweroff.target 0 runlevel0.target Stop the system and power off.

Figure 2: SystemV runtime level compared to Systemd targets and some target aliases

Each target has a dependency set described in its configuration file. Systemd starts the necessary dependencies that are the services needed to run Linux hosts to specific functional levels. When all the dependencies listed in the target profile are loaded and running, the system is running at that target level. In Figure 2, the target with the most features is located at the top of the table, and features decrease from top to bottom.

Systemd also checks the old SystemV init directory to see if there are any startup files. If so, Systemd uses them as configuration files to start the services they describe. A good example is the Network service, which still uses the SystemV startup file in Fedora.

Figure 3 (below) is copied directly from the startup man page. It shows the general sequence of events during systemd startup and the basic sequence required to ensure a successful startup.

                                        cryptsetup-pre.target
                                                   |
 (various low-level                                v
     API VFS mounts:                 (various cryptsetup devices...)
  mqueue, configfs,                                |    |
  debugfs, ...)                                    v    |
  |                                  cryptsetup.target  |
  |  (various swap                                 |    |    remote-fs-pre.target
  |   devices...)                                  |    |     |        |
  |    |                                           |    |     |        v
  |    v                       local-fs-pre.target |    |     |  (network file systems)
  |  swap.target                       |           |    v     v                 |
  |    |                               v           |  remote-cryptsetup.target  |
  |    |  (various low-level  (various mounts and  |             |              |
  |    |   services: udevd,    fsck services...)   |             |    remote-fs.target
  |    |   tmpfiles, random            |           |             |             /
  |    |   seed, sysctl, ...)          v           |             |            /
  |    |      |                 local-fs.target | | / | | | | | | / \____|______|_______________ ______|___________/ | / \ / | / v | / sysinit.target | / | |  / ______________________/|\_____________________ | / / | | | \ | / | | | | | | / v v | v | | / (various (various | (various | |/ timers...) paths...) | sockets...) | | | | | | | | v v | v | | timers.target paths.target | sockets.target | | | | | | v | v \_______ | _____/ rescue.service | \|/ | | v v | basic.target rescue.target | | | ________v____________________ | / | \ | | | | | v v v | display- (various system (various system | manager.service services services) | | requiredfor        |            |
                      |        graphical UIs)       v            v
                      |              |            multi-user.target
 emergency.service    |              |              |
         |            \_____________ | _____________/
         v                          \|/
 emergency.target                    v
                              graphical.target
Copy the code

Figure 3: Systemd startup diagram

Sysinit. target and basic.target targets can be thought of as checkpoints during startup. Although one of systemd’s design goals is to start system services in parallel, certain services and functional targets must be started before others can be started. These checkpoints cannot be passed until all the services and objectives required for the checkpoint are met.

Sysinit. Target is reached when all the cells on which sysinit. Target depends are complete. All of these units, including mounting file systems, setting up swap files, starting Udev, setting up random number generator seeds, starting low-level services, and configuring security services (if one or more file systems are encrypted) must be done, but in sysinit.target, these tasks can be performed in parallel.

Sysinit. target launches all low-level services and units needed to get the system close to normal operation, and to get into basic.target.

After completing sysinit.target, Systemd starts all the cells needed to achieve the next target. Basic.target provides some additional functionality by launching all units required for the next target. This includes setting up paths to various executable directories, setting up communication sockets and timers, and so on.

Finally, the user-level target multi-user. Target or graphical. Target is initialized. To satisfy the dependence of graphical. Target, you must first reach multi-user. Target. The underlined targets in Figure 3 are the usual startup targets. When one of these goals is reached, startup is complete. If multi-user.target is the default, you should see a text-mode login screen on the console. If graphical. Target is the default, you should see a graphical login screen. The specific GUI login screen you see depends on your default display manager.

The boot man page also describes and provides diagrams of the boot to initialized RAM disk and Systemd shutdown process.

Systemd also provides a tool that lists the complete startup process or dependencies for a given unit. A cell is a controlled Systemd resource entity that can range from a specific service (such as HTTPD or SSHD) to timers, mounts, sockets, and so on. Try the following commands and scroll to see the results.

systemctl list-dependencies graphical.target
Copy the code

Note that this fully expands the list of top-level target units needed to put the system into graphical. Target mode. You can also use the –all option to expand all other cells.

systemctl list-dependencies --all graphical.target
Copy the code

You can use the less command to search for strings like target, slice, and socket.

Now try the following.

systemctl list-dependencies multi-user.target
Copy the code

and

systemctl list-dependencies rescue.target
Copy the code

and

systemctl list-dependencies local-fs.target
Copy the code

and

systemctl list-dependencies dbus.service
Copy the code

This tool helps me visualize the startup dependency details of the host I’m using. Continue to spend some time exploring the boot tree of one or more Linux hosts. Be careful, though, because the Systemctl man page contains the following comments:

“Note that this command lists only the units currently loaded into memory by the service manager. In particular, this command is simply not suitable for getting a full list of reverse dependencies for a particular cell, because it does not list dependencies declared by the cell but not loaded.”

The closing

Even without delving into Systemd, it is obvious that it is both powerful and complex. Clearly, Systemd is not a single, large, stand-alone, unknowable binary. Instead, it is made up of many smaller components and subcommands designed to perform specific tasks.

The next article in this series will explore systemd startup in more detail, along with systemd configuration files, changing default targets, and how to create simple service units.

resources

There is plenty of systemd information on the Internet, but much of it is brief, obscure, and even misleading. In addition to the resources mentioned in this article, the following pages provide more detailed and reliable information about Systemd startup.

  • The Fedora project has a very useful systemd guide. It has almost everything you need to know to configure, manage, and maintain Fedora hosts with Systemd.
  • The Fedora project also has a nice shorthand table that relates the old SystemV commands to the contrasted Systemd commands.
  • For detailed technical information about Systemd and why it was created, see Freedesktop.org’s description of Systemd.
  • Linux.com’s “Systemd more Fun” offers more advanced Systemd information and tips.

There is also a series of highly technical articles aimed at Linux system administrators by Systemd designer and lead developer Lennart Poettering. The articles were written between April 2010 and September 2011, but they are as useful now as they were then. Many other good articles about Systemd and its ecology have been based on these papers.

  • Rethink process 1
  • Systemd System administrator part I
  • Systemd System Administrator Part II
  • Systemd System Administrator Part III
  • Systemd System Administrator Part IV
  • Systemd System Administrator part V
  • Systemd System Administrator VI
  • Systemd System Administrator Part VII
  • Systemd System Administrator Part VIII
  • Systemd System Administrator Part IX
  • Systemd System Administrator X
  • Systemd System Administrator part XI

Via: opensource.com/article/20/…

Author: David Both (Lujun9972

This article is originally compiled by LCTT and released in Linux China