Shulou(Shulou.com)05/31 Report--

This article will explain in detail what is the function of systemd after startup and startup. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Systemd is the mother of all processes and is responsible for booting the Linux host to a state that can do productive tasks.

Systemd (yes, all lowercase, even at the beginning of a sentence) is a modern replacement for initializers (init) and SystemV initialization scripts. In addition, it has more functions.

When I think of init and SystemV initialization, like most system administrators, I think of the startup and shutdown of Linux, rather than real management services, such as managing services after they are up and running. Like init, systemd is the mother of all processes and is responsible for booting the Linux host to a state that can do productive tasks. Some of the functions set by systemd are much more extensive than the old initialization program, and it manages many aspects of running Linux hosts, including mounting file systems, managing hardware, processing timers, and system services needed to start and manage production hosts.

The following is a discussion of the functions of systemd after startup and completion.

Linux boot

The complete startup process of a Linux host from shutdown state to running state is complex, but it is open and knowable. Before introducing it in detail, I will briefly introduce the process from when the host hardware is powered on to when the system is ready for user login. Most of the time, the "boot 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: initializing system hardware

Linux

Boot (boot)

: load Linux kernel and systemd

Linux

Start (startup)

Systemd prepares for the productive work of the mainframe

The Linux startup phase begins after the kernel loads init or systemd (depending on whether the specific distribution uses the old or new approach). Init and systemd programs start and manage all other processes, which are called "mothers of all processes" on their respective systems.

Understanding their differences and their role in bringing the Linux system into production allows you to manage these processes and better determine what most people call a "startup" problem.

The startup process follows the three-step boot process to make the Linux computer into a state where production work can be carried out. When the kernel transfers control of the host to systemd, the boot process begins.

Systemd dispute

Systemd has aroused widespread controversy among system administrators and other people responsible for maintaining the normal operation of the Linux system.

SystemV and systemd are two different methods to perform Linux startup. SystemV startup scripts and init programs are the old method, while systemd using the target target is the new method. Although most modern Linux distributions use newer systemd for startup, shutdown, and process management, there are still some distributions that are not used. 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 is more open. Use the Bash script to complete the startup. 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 the 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/rcX.d. Where X is the running level number to be started.

Except for the init programs themselves, all of these programs are open and easy to understand scripts. You can read through these scripts and know exactly what happened during startup, but I don't think too many system administrators actually do that. Each startup script is numbered to start the expected services in a specific order. Services are started serially, and only one service can be started at a time.

Systemd, developed by Red Hat's Lennart Poettering and Kay Sievers, is a complex system of large, compiled binary executables that cannot be understood without access to its source code. It is open source, so it is not difficult, but not convenient, to "access its source code". Systemd seems to show a significant refutation of many of the principles of Linux philosophy. As binaries, systemd cannot be opened directly for system administrators to view or make simple changes. Systemd tries to do everything, such as managing 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 an one-stop tool for system management. All of this clearly violates the principle that programs should be small, and each program should only do one thing and do it well.

Why do I prefer systemd?

I prefer to use systemd as the startup mechanism because it starts as many services as possible in parallel according to the startup phase. This speeds up the entire boot speed, allowing the host system to reach the login screen faster than SystemV.

Systemd can manage almost every aspect of a running Linux system. It can manage running services and provide much more status information than SystemV. It also manages hardware, processes and process groups, file system mounts, and so on. Systemd is involved in almost every aspect of modern Linux operating system, making it an one-stop tool for system management. Does that sound familiar? )

The startup configuration can be modified through a variety of GUI and command-line tools, and various configuration files can be added or modified to meet the needs of a specific local computing environment.

The real problem.

Do you think I can't like the two boot systems? I can. I'll use any of them.

I think the real problem and root cause of most of the disputes between SystemV and systemd is that there is no choice at the system management level. Whether to use SystemV or systemd has been chosen (but with good reason) by developers, maintainers, and packers of various distributions. Due to the extremely intrusive nature of init, digging up and replacing init systems will have a lot of impact and bring a lot of consequences that are difficult to solve outside the release design process.

Although the choice is actually for me, I am most concerned about whether my Linux host can be turned on and work. As an end user and even a system administrator, my main concern is whether I can do my work, such as writing my book and this article, installing updates, and writing scripts to automate everything.

I care when there is a problem with startup or service management.

Replace SystemV

There have been attempts to replace SystemV with something more modern. In about two versions, Fedora uses something called Upstart to replace the aging SystemV, but it doesn't replace init and doesn't provide any of the changes I've noticed. Since Upstart didn't make any significant changes to SystemV's problems, efforts in this direction were quickly 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 rediscussing all the so-called problems that people encounter or have encountered in systemd, let's take you to two good articles that, though stale, cover most of the content. Linus Torvalds, the creator of the Linux kernel, doesn't seem to be interested in systemd.

If you don't know much about Linus, I can tell you that if he doesn't like something, he is very outspoken, very clear, and quite clear that he doesn't like it. His way of solving his dissatisfaction with things has been better accepted by the society.

In 2013, Poettering wrote a long blog in which he refuted the myth about systemd and made an in-depth analysis of some of the reasons for creating systemd. This is a very good reading material, I strongly suggest you read 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:

The systemd program runs as process 1 (PID 1) and provides system startup capabilities to enable as many services as possible to start in parallel, which additionally speeds up the overall startup time. It also manages the shutdown sequence.

The systemctl program provides a user interface for service management.

Support for SystemV and LSB startup scripts for backward compatibility.

Service management and reporting provide more service status data than SystemV.

Provides basic system configuration tools, such as hostname, date, locale, list of logged-in users, running containers and virtual machines, system accounts, runtime directories and settings, daemons for easy network configuration, network time synchronization, log forwarding, and name resolution.

Provide socket management.

Systemd timers provide advanced features similar to cron, including running scripts at a point in time relative to system startup, systemd startup time, and timer last start time.

It provides a tool to analyze the date and time used in the timer specification.

Hierarchical file system mount and unmount capabilities allow for more secure cascading of mounted file systems.

Allows you to proactively create and manage temporary files, including deletion.

D-Bus 's interface provides the ability to run scripts when a device is inserted or removed. This allows all devices (pluggable or not) to be treated as plug and play, greatly simplifying the handling of devices.

Tools that analyze startup steps can be used to find the most time-consuming services.

It includes logs for storing system messages and tools for managing logs.

Architecture

These and more tasks are supported by many daemons, controls, and configuration files. Figure 1 shows many of the components that belong to systemd.

The architecture of 1:systemd, by Shmuel Csaba Otto Traian (CC BY-SA 3.0)

You need a book if you want to explain systemd completely. You don't need to know the details of how the systemd components in figure 1 fit together.

As the systemd of process 1

Systemd is process 1 (PID 1). Some of its features, much more extensive than the old SystemV3 init, are used to manage many aspects of a running Linux host, including mounting file systems and system services required to start and manage Linux production hosts. Any systemd tasks that have nothing to do with startup are beyond the scope of this article (but some of these tasks will be discussed in later articles in this series).

It uses its configuration link / etc/systemd/system/default.target to determine which state or destination the host is booted to. The default.target file is a symbolic link to the real target file. For desktop workstations, it is usually graphical.target, which is equivalent to runlevel 5 in SystemV. For servers, the default value is more likely to be multi-user.target, which is equivalent to runlevel 3 in SystemV. Emergency.target is similar to single-user mode. The target target and the service service are the unit unit of the systemd.

The following table (figure 2) compares the systemd target with the old SystemV startup run level. Systemd provides systemd target aliases for backward compatibility. Of course, the SystemV command is forwarded to systemd for interpretation and execution.

The systemd target SystemV runlevel target alias describes default.target this target always becomes an alias for multi-user.target or graphical.target by symbolic connection. Systemd always uses default.target to start the system. Default.target should never be set as an alias for halt.target,poweroff.target or reboot.target. Graphic.target5runlevel5.target multi-user.target with GUI. 4runlevel4.target is not used. Run level 4 is the same as run level 3 in SystemV. You can create and customize this target to start local services without changing the default multi-user.target. Multi-user.target3runlevel3.target all services are running, but only the command line interface (CLI). 2runlevel2.target multi-user, no NFS, all other non-GUI services are running. The rescue.target1runlevel1.target basic system, including mounting the file system, running the most basic services, and the recovery shell of the primary console. Emergency.targetS single-user mode: no service runs; no file system is mounted. This is the most basic level of work, and there is only an emergency Shell running on the main console for users to interact with the system. Halt.target stops the system without powering off. Reboot.target6runlevel6.target restarts. Poweroff.target0runlevel0.target stops the system and powers off.

Figure comparison of 2:SystemV runlevels with systemd targets and some target aliases

Each target describes a dependency set in its configuration file. Systemd starts the necessary dependencies, which are the services required to run the Linux host to a specific functional level. When all the dependencies listed in the target configuration file are loaded and run, the system runs at that target level. In figure 2, the goal with the most functionality is at the top of the table, gradually decreasing from top to bottom.

Systemd also checks the old SystemV init directory to see if any startup files exist. If so, systemd uses them as configuration files to start the services they describe. A good example is the web 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 events during systemd startup and the basic sequence requirements 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 | / (various (various) | (various) | | / timers...) Paths...) | sockets...) | | v | v | | timers.target paths.target | sockets.target | | | v | v\ _ | _ / rescue.service |\ | / | | v | Basic.target rescue.target | _ v _ | / | |\ | | v | display- (various system (various system | manager.service services services) | | | required for | | graphical UIs) v | | multi-user.target emergency.service |\ _ | _ | _ / v\ | / emergency.target v graphical.target figure 3: systemd startup diagram

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

When all the units on which the sysinit.target depends are complete, the sysinit.target will be reached. 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 completed, but in sysinit.target, these tasks can be performed in parallel.

Sysinit.target starts all the low-level services and units needed for the system to be close to normal operation, which are also needed to enter the basic.target.

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

Finally, the user-level target multi-user.target or graphical.target is initialized. To meet the dependency of graphical.target, you must first reach multi-user.target. The underlined target in figure 3 is the usual startup target. When one of these goals is achieved, the startup is complete. If multi-user.target is the default setting, you should see the text mode login screen on the console. If graphical.target is the default setting, then you should see the graphical login interface. The exact GUI login interface you see depends on your default display manager.

The boot man page also describes and provides a diagram of booting to initialize the RAM disk and the systemd shutdown process.

Systemd also provides a tool that lists the complete startup process or the dependencies of the specified unit. A unit is a controllable systemd resource entity that can range from specific services (such as httpd or sshd) to timers, mounts, sockets, and so on. Try the following command and scroll to see the results.

Systemctl list-dependencies graphical.target

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

Systemctl list-dependencies-all graphical.target

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

Now try the following method.

Systemctl list-dependencies multi-user.target

And

Systemctl list-dependencies rescue.target

And

Systemctl list-dependencies local-fs.target

And

Systemctl list-dependencies dbus.service

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

"Note that this command lists only the units that are currently loaded into memory by the service manager. In particular, this command is not suitable for getting a list of all reverse dependencies for a particular unit at all, because it does not list dependencies declared by the unit but not loaded."

Concluding remarks

Even before delving into systemd, it is clear that it is both powerful and complex. Obviously, systemd is not a single, large, single, and unknowable binary file. Instead, it consists of many smaller components and subcommands designed to perform specific tasks.

About what is the function of systemd after startup and startup is shared here, I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.