In-depth analysis of the systemd management system under CentOS 7

CentOS system startup process:

POST --> Boot Sequence --> Bootloader --> kernel initramfs(initrd) --> rootfs --> /sbin/init

innit program:

CentOS 5: SysV init

CetnOS 6: Upstart

CentOS 7 : Systemd

New features of Systemd:

System Sys V init and LSB init scripts are compatible

Implement parallel startup of services during system boot; Use socket/D-Bus activation and other technologies to start services; in order to reduce system startup time, the goal of systemd is: start as few processes as possible; Start more processes in parallel;

Activate processes on demand; Systemd can provide the ability to start on demand, starting a service only when it is actually requested. When the service ends, systemd can shut it down and start it again the next time it is needed.

Ability to snapshot and restore the system;

Start the management of mount points and automatic mount points:

Systemd self-manages mount points on the system so that they can be automatically mounted at system startup. And compatible with /etc/fstab file;

Implement transaction dependency management:

systemd maintains a concept of "transaction consistency" to ensure that all related services can be started normally without interdependence or deadlock.

Define service control logic based on endogenous dependencies;

system uses the feature of the Linux kernel, namely CGroup, to complete the task of process tracking. When stopping the service, by querying the CGroup, systemd can ensure that all related processes are found, thereby stopping the service cleanly;

Log service: systemd comes with its own log service journald. The original design of this log service is to overcome the shortcomings of the existing syslog service.

Basic concepts of System

The concept of unit:

There are many things that need to be done during system initialization. Background services need to be started, such as starting the SSHD service; configuration work needs to be done, such as mounting the file system. Each step in this process is abstracted by systemd into a configuration unit, that is, unit. You can think of a service as a configuration unit; a mount point as a configuration unit; the configuration of a swap partition as a configuration unit; and so on. systemd classifies hives into some different types: However, systemd is evolving rapidly and new features are constantly being added. So hive types may continue to increase in the near future.

service: represents a background service process, such as mysqld. This is a commonly used category;

socket: This hive encapsulates a socket in the system and the Internet. Currently, systemd supports streaming, packet, and continuous packet AF_INET, AF_INET6, and AF_UNIX sockets. Every socket hive has a corresponding service hive. The corresponding service will be started when the first "connection" enters the socket (for example: nscd.socket starts nscd.service after a new connection).

device : This hive encapsulates a device that exists in the Linux device tree. Every device tagged with a udev rule will appear in systemd as a device hive.

mount: This type of hive encapsulates a mount point in the file system structure hierarchy. Systemd will monitor and manage this mount point. For example, it can be automatically mounted at startup; it can be automatically uninstalled under certain conditions. Systemd will convert all entries in /etc/fstab into mount points and process them at boot.

automount: This type of hive encapsulates a self-mount point in the system structure hierarchy. Each self-mounting hive corresponds to a mounting hive. When the automatic mount point is accessed, systemd executes the mounting behavior defined in the mount point.

swap: Similar to the mount hive, the swap hive is used to manage the swap partition. Users can use swap hives to define swap partitions in the system, allowing these swap partitions to be activated at boot time.

target : This hive provides a logical grouping of other hives. They don't actually do anything themselves, they just reference other hives. This allows for unified control of the configuration unit. This enables the familiar concept of run levels to be implemented. For example, if you want the system to enter graphical mode, you need to run many services and configuration commands. These operations are represented by configuration units one by one. Combining all these configuration units into a target means that all these configuration units need to be executed. Once to enter the system running state represented by the target. (For example: multi-user.target is equivalent to runlevel 3 in systems using traditional SysV)

timer: The timer configuration unit is used to trigger user-defined operations regularly. This type of configuration unit replaces traditional timing services such as atd and crond.

snapshot: Similar to the target hive, a snapshot is a set of hives. It saves the current operating status of the system.

Dependencies:

Although systemd removes a large number of startup tasks from dependencies, allowing them to be started concurrently. However, there are still some tasks that have inherent dependencies between them, and the three major methods of "socket activation" (socket activation), D-Bus activation and autofs cannot be used to relieve the dependence (see the subsequent descriptions for details of the three major methods). For example: the mount must wait for the mount point to be created in the file system; the mount must also wait for the corresponding physical device to be ready. In order to solve this kind of dependency problem, systemd configuration units can define dependencies on each other.

Systemd uses keywords in the hive definition file to describe the dependencies between hives. For example: unit A depends on unit B, which can be represented by "require A" in the definition of unit B. In this way, systemd will ensure that A is started first and then B.

Systemd Transactions:

Systemd can guarantee transaction integrity. Systemd's transaction concept is different from that in the database, mainly to ensure that there are no circular references between multiple dependent configuration units. If there is a circular dependency, systemd will not be able to start any service. At this time systemd will try to solve this problem, because there are two types of dependencies between hives: required is a strong dependency; want is a weak dependency. systemd will remove the dependency specified by the wants keyword to see if it can break the cycle. If it cannot be repaired, systemd will report an error.

Systemd can automatically detect and repair such configuration errors, greatly reducing the administrator's troubleshooting burden.

Target and runlevel:

systemd replaces the concept of run level with target, providing greater flexibility. For example, you can inherit an existing target and add other services to create your own target. The following table lists the corresponding relationships between targets under systemd and common runlevels:

Concurrent startup principle of Systemd

As mentioned before, in Systemd, all services are started concurrently, such as Avahi, D-Bus, livirtd, X11, and HAL can be started at the same time. At first glance, this seems to be a bit of a problem. For example, Avahi needs the syslog service. Avahi and syslog are started at the same time. Assuming that Avahi starts faster, syslog is not ready yet, but Avahi needs to record logs. Wouldn't this cause problems? ?

Systemd developers carefully studied the nature of interdependence between services and found that so-called dependencies can be divided into three specific types, and each type can actually eliminate dependencies through corresponding technologies.

One of the principles of concurrent startup: solving socket dependency

The vast majority of service dependencies are socket dependencies. For example, service A provides its own services through a socket port S1. If other services need service A, they need to connect to S1. So if service A has not been started yet, S1 does not exist and other services will get startup errors. So traditionally, people need to start service A first, wait for it to enter the ready state, and then start other services that need it. Systemd believes that as long as we create S1 in advance, all other services can be started at the same time without waiting for service A to create S1. If service A has not been started, then the service request sent by other processes to S1 will actually be cached by the Linux operating system, and other processes will wait at the location of this request. Once service A is up and running, cached requests can be processed immediately and everything starts running normally.

So how does the service use the socket created by the init process?

The Linux operating system has a feature. When a process calls fork or exec to create a child process, all file descriptors opened in the parent process are inherited by the child process. A socket is also a kind of file handle. Process A can create a socket. After that, when process A calls exec to start a new child process, as long as the close_on_exec flag of the socket is cleared, then the new child process You can inherit this socket. The socket seen by the child process and the socket created by the parent process are the same system socket, as if the socket was created by the child process itself, there is no difference.

This feature was previously exploited by a system service called inetd. The Inetd process is responsible for monitoring some common socket ports, such as Telnet. When there is a connection request on the port, inetd starts the telnetd process and passes the connected socket to the new telnetd process for processing. In this way, when the system does not have a telnet client connection, there is no need to start the telnetd process. Inetd can proxy many network services, which can save a lot of system load and memory resources. The corresponding service will only be started when there is a real connection request, and the socket will be passed to the corresponding service process.

Similar to inetd, systemd is the parent process of all other processes. It can first establish all required sockets, and then pass the socket to the new service process when calling exec, and the new process uses it directly The socket can be serviced.

Concurrent startup principle 2: Solving D-Bus Dependencies

D-Bus is the abbreviation of desktop-bus. It is an inter-process communication mechanism with low latency, low overhead and high availability. It is increasingly used for communication between applications, but also for communication between applications and the operating system kernel. Many modern service processes use D-Bus instead of sockets as the inter-process communication mechanism to provide external services. For example, the NetworkManager service that simplifies Linux network configuration uses D-Bus to interact with other applications or services: the email client software evolution can obtain changes in network status from the NetworkManager service through D-Bus in order to handle it accordingly.

D-Bus supports the so-called "busactivation" function. If service A needs to use the D-Bus service of service B, and service B is not running, D-Bus can automatically start service B when service A requests the D-Bus of service B. The request issued by service A will be cached by D-Bus, and service A will wait for service B to be ready. Using this feature, services that rely on D-Bus can be started in parallel.

The third principle of concurrent startup: resolving file system dependencies

During the system startup process, file system-related activities are the most time-consuming. For example, mounting the file system, performing disk check (fsck) on the file system, and disk quota check are all very time-consuming operations. While waiting for this work to complete, the system sits idle. Services that want to use the file system seem to have to wait for the file system initialization to complete before they can start. But systemd found that this dependency can also be avoided.

Systemd refers to the design ideas of autofs, so that services that rely on the file system and the initialization of the file system itself can work concurrently. autofs can detect when a file system mount point is actually accessed before triggering the mount operation. This is achieved through the support of the kernel automounter module. For example, when an open() system call is executed on "/misc/cd/file1", /misc/cd has not yet performed the mounting operation. At this time, the open() call is suspended and waits. The Linux kernel notifies autofs, and autofs performs the mounting operation. . At this time, control is returned to the open() system call and the file is opened normally.

Systemd integrates the implementation of autofs. For mount points in the system, such as /home, when the system starts, systemd creates a temporary automatic mount point for it. At this moment, the real mounting device of /home has not yet been started, the real mounting operation has not been performed, and the file system detection has not yet been completed. However, processes that rely on this directory can already be started concurrently, and their open() operations are captured by autofs built into systemd, which suspends the open() call (which can interrupt the sleep state). Then, after the actual mount operation is completed and the file system detection is completed, systemd replaces the automatic mount point with the real mount point and lets the open() call return. As a result, services that rely on the file system and the file system itself can be started concurrently.

Of course, dependence on the "/" root directory must actually be executed serially, because systemd itself is also stored under /, and must wait for the system root directory to be mounted and checked.

However, for mount points such as /home, this concurrency can improve the startup speed of the system, especially when /home is a remote NFS node, or an encrypted disk, etc., it will take a long time to be ready. In this case, due to concurrent startup, the system does not have nothing to do during this period, but can use this free time to do more startup processes, which overall shortens the system startup time.

Systemd Usage

The following is a brief introduction to the use of systemd based on the different roles of technical personnel. This article only intends to give a brief description to give you a general understanding of the use of systemd. There are too many specific details to cover in a short article. Readers need to further consult the systemd documentation themselves.

Unit Writing of files

When developers develop a new service program, such as httpd, they need to write a configuration unit file for it so that the service can be managed by systemd, similar to UpStart's work configuration file. Define the command line syntax for service startup in this file, as well as dependencies on other services.

In addition, we have learned before that systemd has many functions. It is not only used to manage services, but also to manage mount points, define scheduled tasks, etc. These tasks are completed by editing the corresponding hive file. I'm giving a few examples of hive files here.

The following is the configuration unit file of the SSH service. The service configuration unit file has .service as the file name suffix.

[root@kalaguiyin system]# cat/usr/lib/systemd/system/sshd.service

[Unit]

Description=OpenSSH server daemon

After=network.target sshd-keygen.service

Wants=sshd-keygen.service

#[unit] part, description information

[Service]

EnvironmentFile=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=process

Restart=on-failure

RestartSec=42s

#[service] definition, ExecStartPre defines the command that should be run before starting the service;

#ExecStart defines the specific command line syntax for starting the service.

[Install]

WantedBy=multi-user.target

#[install] section: WangtedBy indicates that this service is required in multi-user mode.

Then let’s take a look at multi-user.target:

[root@kalaguiyin system]# catmulti-user.target

[Unit]

Description=Multi-User System

Documentation=man:systemd.special(7)

Requires=basic.target

Conflicts=rescue.service rescue.target

After=basic.target rescue.servicerescue.target

AllowIsolate=yes

# The Requires definition indicates that when multi-user.target starts, basic.target must also be started; in addition, when basic.target stops, multi-user.target must also stop. If you then look at the basic.target file, you will find that it also specifies sysinit.target

# Other units must be started accordingly. Similarly sysinit.target will also contain other units. Using such a layer-by-layer link structure, eventually all component services that need to support multi-user mode will be initialized and started.

[Install]

Alias=default.target

# Alias ​​definition means defining the alias of this unit, so that you can use this alias to reference this unit when running systemctl.

In addition, you can also see directories such as *.wants in the /etc/systemd/system directory. The configuration unit file placed in this directory is equivalent to the wants keyword in the [Unit] section, that is, the unit starts , these units also need to be started. For example, you can simply put the foo.service file you wrote yourself into the multi-user.target.wants directory, so that it will be started by default every time.

[root@kalaguiyin system]# pwd

/etc/systemd/system

[root@kalaguiyin system]# ls

basic.target.wants                                                                                                   display-manager.service

bluetooth.target.wants                                                                                

dbus-org.bluez.service           graphical.target.wants

printer.target.wants                                                                                                                                                                                                                                                                                    sockets.target.wants

spice-vdagentd.target.wants                                                                              .target.wants

Let us take a look at the sys-kernel-debug.mout file again. This file defines a file mount point:

[root@kalaguiyin system]# cat

sys-kernel-debug.mount

[Unit]

Description=Debug File System

Documentation=https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt

Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

DefaultDependencies=no

ConditionPathExists=/sys/kernel/debug

Before=sysinit.target

[Mount]

What=debugfs

Where=/sys/kernel/debug

Type=debugfs

This hive file defines a mount point. The mounting hive file has a [Mount] configuration section, which contains three data items: What, Where and Type. These are required for the mount command. The configuration in the example is equivalent to the following mount command:

mount –t debugfs /sys/kernel/debug debugfs

SystemdSystem Management:

The main command line tool of systemd is systemctl.

Most administrators should already be very familiar with the management of system services and init systems, such as the use of service, chkconfig and telinit commands. systemd also performs the same management tasks, but the syntax of the command tool systemctl is different.

Start service

systemctl start httpd.service as shown in Figure 1:

Out of service

systemctl stop httpd.service as shown in Figure 2:

Restart service

systemctl restarthttpd.service as shown in Figure 3:

Reload service

systemctl reloadhttpd.service

Conditional restart

systemctl condrestarthttpd.service

Status View

systemctl statushttpd.service

List the services that can be started or stopped.

systemctl list-unit-files –type=service

Set the service to start at boot

chkconfig httpd on

systemctl enablehttpd.service

Cancel service startup;

systemctl disablehttpd.service

Check whether a service is configured to be enabled or disabled in the current environment.

systemctl is-enabledhttpd.service;echo $?

Output the enabling and disabling of services at each run level

systemctl list-unit-files –type=service

Lists the runlevels at which a service is enabled and disabled.

ls /etc/lib/systemd/system/*.wants/httpd.service

Change user run level:

systemctl isolatemulti-user.target

multi-user.target == 3rd run level

graphical.target == 5th run level

runlevel3.target symbolic link, pointing to multi-user.target

runlevel5.target symbolic link, pointing to graphical.target

Change the default runlevel:

[root@kalaguiyinsystem]# systemctl set-default multi-user.target

rm'/etc/systemd/system/default.target'

ln -s'/usr/lib/systemd/system/multi-user.target''/etc/systemd/system/default.target'

The essence of the above operation is to delete /usr/lib/systemd/system/default.target, and then link the target level target file to the /etc/systemd/system/default.target file;

systemd is no longer just an initialization system:

systemd is also responsible for other management configurations of the system, such as network configuration, Locale management, and management of system kernel module loading, etc.

Systemd does an excellent job of replacing all the functions of sysvinit, but it is not complacent. Because the init process is the parent process of all processes in the system, systemd is very suitable for providing functions once provided by other services, such as scheduled tasks (previously completed by crond); session management (previously managed by ConsoleKit/PolKit, etc.). Judging from the superficial introduction in this article, Systemd has already taken care of a lot, but it is still developing. It will gradually become a multi-functional system environment capable of handling many system management tasks. Some people even regard it as an operating system. This is great for standardizing Linux management!

The above is the detailed content of In-depth analysis of the systemd management system under CentOS 7. For more information, please follow other related articles on the PHP Chinese website!