Shulou(Shulou.com)06/01 Report--

This article is about the sample analysis of systemd management in CentOS 7. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

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

What's new in Systemd:

System Sys V init is compatible with LSB init scripts

When the system is booted, the service is started in parallel; socket / D-Bus activation and other technologies are used to start the service; in order to reduce the system startup time, the goal of systemd is to start as few processes as possible, and to start as many processes in parallel as possible

Activate the process on demand; Systemd provides 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 wait for it to be started again the next time it is needed.

Ability to snapshot and restore the system

Start the management of mount point and auto mount point:

Systemd self-management mount points on the system so that they can be mounted automatically when the system starts. 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 and deadlock.

Define service control logic based on endogenous dependency

System uses the feature of the Linux kernel, namely CGroup, to complete the task of process tracking. When stopping the service, you can ensure that all relevant processes are found by querying CGroup,systemd, thus stopping the service cleanly.

Log service: systemd has its own log service journald, which is originally designed to overcome the shortcomings of existing syslog services.

The basic concept of System

The concept of unit:

There are many things that need to be done to initialize the system. Background services need to be started, such as SSHD services, and 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, unit. You can think of a service as a configuration unit; a mount point as a configuration unit; a swap partition configuration as a configuration unit; and so on. Systemd classifies the configuration units into the following different types. However, systemd is developing rapidly and new features are increasing. So configuration unit types may continue to increase in the near future.

Service: represents a background service process, such as mysqld. This is a common kind.

Socket: this type of configuration unit encapsulates a socket in the system and the Internet. Currently, systemd supports streaming, packet and continuous packet AF_INET, AF_INET6, AF_UNIX socket. Each socket configuration unit has a corresponding service configuration unit. The corresponding service starts as soon as the first "connection" enters the socket (for example, nscd.socket starts nscd.service after a new connection).

Device: this type of configuration unit encapsulates a device that exists in the Linux device tree. Each device marked with udev rules will appear as a device configuration unit in systemd.

Mount: this type of configuration unit encapsulates a mount point in the file system structure hierarchy. Systemd will monitor and manage this mount point. For example, it can be mounted automatically at startup; it can be uninstalled automatically under certain conditions. Systemd converts all the entries in / etc/fstab to mount points and processes them at boot time.

Automount: this type of configuration unit encapsulates a self-mount point in the system architecture hierarchy. Each self-mount configuration unit corresponds to a mount configuration unit, and when the automatic mount point is accessed, the systemd executes the mount behavior defined in the mount point.

Swap: similar to the mount configuration unit, the switch configuration unit is used to manage the switching partition. The user can use the switching configuration unit to define the switching partitions in the system, which can be activated at startup.

Target: this type of configuration unit logically groups other configuration units. They don't actually do anything by themselves, they just refer to other configuration units. In this way, we can have a unified control over the configuration unit. This makes it possible to implement the run-level concept that everyone is already familiar with. For example, if you want the system to enter graphical mode, you need to run many services and configuration commands, which are represented by individual configuration units. Combining all these configuration units into a target means that you need to execute all these configuration units in order to enter the running state of the system represented by the target. (for example, multi-user.target is equivalent to running level 3 on a traditional system that uses SysV)

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

Snapshot: similar to the target configuration unit, a snapshot is a set of configuration units. It saves the current running state of the system.

Dependencies:

Although systemd frees a lot of startup work from dependency, allowing them to start concurrently. However, there are still some tasks that are inherently dependent on each other and cannot be undependent with "socket activation" (socket activation), D-Bus activation, and autofs (details of the three methods are described later). For example, the mount must wait for the mount point to be created in the file system, and the mount must wait for the corresponding physical device to be ready. To solve this kind of dependency problem, the configuration units of systemd can define dependencies on each other.

Systemd uses keywords in the configuration unit definition file to describe the dependencies between configuration units. For example, unit A depends on unit B, which can be represented as "require A" in the definition of unit B. In this way, systemd will make sure that A starts first and then B.

Systemd transactions:

Systemd can guarantee transaction integrity. The transaction concept of Systemd 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 of the services. At this point, systemd will try to solve this problem because there are two kinds of dependencies between configuration units: required is a strong dependency; want is a weak dependency, and 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 fix this kind of configuration errors, which greatly reduces the debugging burden of administrators.

Target and runlevel:

Systemd replaces the concept of runtime level with target, providing more flexibility, such as you can inherit an existing goal and add other services to create your own goals. The following table lists the correspondence between goals under systemd and common runlevel:

The principle of concurrent Startup of Systemd

As mentioned earlier, in Systemd, all services are started concurrently, such as Avahi, D-Bus, livirtd, X11, and HAL. At first glance, this seems to be a bit of a problem. For example, Avahi needs syslog services, and Avahi and syslog start at the same time. Suppose Avahi starts relatively fast, so syslog is not ready yet, but Avahi needs to log. Isn't that a problem?

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

One of the principles of concurrent startup: solving socket dependency

Most service dependencies are socket dependencies. For example, service A provides its own services through a socket port S1, while other services need to connect to S1 if they need service A. So if service A has not been started, S1 does not exist and other services will get a startup error. 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 set up 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, service requests sent by other processes to S1 will actually be cached by the Linux operating system, and other processes will wait at the place of the request. Once service An is started and ready, the cached request can be processed immediately, and everything starts to run normally.

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

The Linux operating system has a feature that when a process calls fork or exec to create a child process, all file handles (file descriptor) that are opened in the parent process are inherited by the child process. A socket is also a file handle, and process A can create a socket, and then when process A calls exec to start a new child process, just make sure that the close_on_exec flag bit of the socket is cleared, then the new child process can inherit the socket. The socket that the child process sees and the socket created by the parent process is the same system socket as if the socket was created by the child process itself, and 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 that 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 a lot of network services, so it can save a lot of system load and memory resources, only when there is a real connection request to start the corresponding service, and pass the socket to the corresponding service process.

Like inetd, systemd is the parent of all other processes. It can first create all the required sockets and then pass the socket to the new service process when the exec is called, and the new process can use the socket to serve directly.

The second principle of concurrent startup: solving D-Bus dependency

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

D-Bus supports the so-called "busactivation" feature. 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. Requests made by Service A will be cached by D-Bus, and Service A will wait for Service B to start and be ready. With this feature, services that rely on D-Bus can be started in parallel.

The third principle of concurrent startup: solving file system dependency

During the system startup process, the file system-related activities are the most time-consuming, such as mounting the file system, fsck of the file system, disk quota check and so on. While waiting for these tasks to be completed, the system is idle. Services that want to use the file system seem to have to wait for the file system to be initialized before they can start. But systemd found that this dependency could also be avoided.

Systemd refers to the design idea of autofs, so that the service that depends on the file system and the initialization of the file system itself can work concurrently. Autofs can detect that a file system mount point is actually accessed before triggering the mount operation, which is supported by the kernel automounter module. For example, when an open () system call acts on "/ misc/cd/file1", / misc/cd has not yet performed the mount operation, and the open () call is suspended and waited, and the Linux kernel tells autofs,autofs to perform the mount. At this point, control is returned to the open () system call and the file is opened normally.

Systemd integrates the implementation of autofs, and for mount points in the system, such as / home, systemd creates a temporary automatic mount point for the system when the system starts. At this point / home the real mount device has not been started, the real mount operation has not been performed, and the file system test has not been completed. However, processes that depend on this directory can be started concurrently, and their open () operations are captured by the autofs built into systemd, suspending the open () call (interruptible sleep state). Then wait for the real mount operation to complete and after the file system detection is complete, systemd replaces the automatic mount point with the real mount point and lets the open () call return. As a result, services that depend on the file system and the file system itself are started concurrently.

Of course, the dependency on the "/" root directory must actually be executed serially, because the 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, which takes a long time to be ready, because of concurrent startup, the system is not completely idle during this period of time, but can use this spare time to do more things to start the process. Overall, it shortens the startup time of the system.

The use of Systemd

The following is a brief introduction to the use of systemd for the different roles of technicians. This article is only intended to give you a brief description to give you a general understanding of the use of systemd. There are too many details, that is, it is impossible to write them all in a short article. Readers are also required to further consult the systemd documentation themselves.

The compilation of Unit file

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 the working configuration file of UpStart. Define the command line syntax for service startup and dependencies with other services in this file.

In addition, we have learned before that systemd has a variety of functions, not only to manage services, but also to manage mount points, define scheduled tasks, and so on. All this work is done by editing the corresponding configuration unit file. Here I give several examples of configuration unit files.

The following is the configuration unit file for the SSH service, with .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] section, 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 commands 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.

So 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 definition of # Requires indicates that basic.target must also be started when multi-user.target is started, and multi-user.target must also be stopped when basic.target stops. If you go on to look at the basic.target file, you will find that it specifies sysinit.target again

# other units must be started with it. The sysinit.target will also contain other units. With this layer-by-layer link structure, all component services that need to support multi-user mode will eventually be initialized and started.

[Install]

Alias=default.target

The # Alias definition, which defines the alias of this unit, so that you can use this alias to refer to this unit when running systemctl.

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

[root@kalaguiyin system] # pwd

/ etc/systemd/system

[root@kalaguiyin system] # ls

Basic.target.wants display-manager.service

Bluetooth.target.wants getty.target.wants

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

Printer.target.wants sockets.target.wants

Spice-vdagentd.target.wants default.target sysinit.target.wants default.target.wants

Let's take a look at the sys-kernel-debug.mout file, which 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 configuration unit file defines a mount point. The mount configuration unit file has a [Mount] configuration section in which three data items, What,Where and Type, are configured. This is all necessary for the mount command, and the configuration in the example is equivalent to the following mount command:

Mount-t debugfs / sys/kernel/debug debugfs

Systemd system Management:

The main command line tool for systemd is systemctl.

Most administrators should already be familiar with system services and the management of init systems, such as the use of service, chkconfig, and telinit commands. Systemd performs the same administrative task, except that the syntax of the command tool systemctl is different.

Start the service

Systemctl start httpd.service is shown in figure 1:

Out of Service

Systemctl stop httpd.service is shown in figure 2:

Restart the service

Systemctl restarthttpd.service is shown in figure 3:

Overloaded service

Systemctl reloadhttpd.service

Conditional restart

Systemctl condrestarthttpd.service

Status View

Systemctl statushttpd.service

Lists the services that can be started or stopped.

Systemctl list-unit-files-type=service

Set the service to boot.

Chkconfig httpd on

Systemctl enablehttpd.service

Cancel service boot and start

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 under which a service is enabled and disabled.

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

Change the user run level:

Systemctl isolatemulti-user.target

Multi-user.target = = runlevel 3

Graphical.target = = runlevel 5

Runlevel3.target symbolic link to multi-user.target

Runlevel5.target symbolic link to graphical.target

Change the default run level:

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

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

Ln-swords Universe SystemSystemSystemSystemSystemSystemUniSystemSystemUniSystemSystedSystemSystedSystemSystedUniSystemSystemSystedSystemSystemSystemSystemSystemSystedSystemSystemSystemSystemUniverse system

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 system management configurations, such as configuring the network, Locale management, managing system kernel module loading and so on.

Systemd excellently replaces all the functions of sysvinit, but it is not complacent. Because of the particularity that the init process is the parent of all processes in the system, systemd is ideal for providing functions that were once provided by other services, such as scheduled tasks (formerly done by crond) and session management (formerly managed by ConsoleKit/PolKit, etc.).

Thank you for reading! This is the end of this article on "sample Analysis of systemd Management in CentOS 7". I hope the above content can be of some help to you, so that you can 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.