Detailed description of systemd

Detailed description of systemd

CentOS 6 and earlier versions use the SysVinit System Boot Process Management System. Generally, you can customize your system startup sequence by configuring the/etc/inittab file. However, the control flow of the serial startup process is often caused by hardware problems in special environments, because the task may be blocked and the startup process is affected.

CentOS 7 starts to use SystemD, so we must understand SystemD.

For details, see RedHat product documentation.
Use systemd Management Service: Chapter 6. Managing Services with systemd

I. Origins of SystemD
SystemD is an init software in Linux. It is developed by Lennart Poettering and is released open-source under LGPL 2.1 and later versions. Lennart is a redhat employee, but SystemD is not a redhat project. Its development goal is to provide a better framework to represent the dependency between system services, and to achieve parallel startup of services during system initialization and reduce the system overhead of Shell, the System V and BSD init programs are replaced.
The name of SystemD originates from a convention in Unix: in Unix, "d" is often used as the suffix identifier of the system daemon. In addition, SystemD also refers to the English term D system, which is used to describe a person's ability to quickly adapt to the environment and solve difficulties.
SystemD is designed to improve the disadvantages of SysVinit and compete with upstart of Ubuntu. Many concepts of SystemD come from Apple's launchd. The goal is to start fewer processes as much as possible, and start more processes in parallel as much as possible (this is the conceptual basis for better performance than SysVinit ). SystemD minimizes the dependency on Shell scripts. Traditional SysVinit uses inittab to determine which Shell scripts to run. A large number of Shell scripts are considered to be the cause of low efficiency and inability to run parallel scripts. SystemD uses the exclusive Linux technology and does not take into account POSIX compatibility. As long as it can meet the needs of social changes and break through some outdated technical constraints, this is also the need of today's innovative ideas, I believe the market will give a judgment.
Compared with the System V-style init used in most releases, SystemD adopts the following new technologies:
● Socket-activated and bus-activated services are used to improve the Parallel Running Performance of mutually dependent services;
● Use cgroups instead of PID to track processes. Therefore, even the daemon generated after two forks will not be out of the control of systemd.
In terms of design concept, because SystemD uses components such as cgroup and fanoidea to implement its features, it is only applicable to Linux. Therefore, software sources based on the kFreeBSD branch cannot be incorporated into SystemD.

Linux boot mode: systemd upstart sysV

Why is systemd so quickly adopted?

Systemd and sysVinit Color comparison table

Linux Kernel EMD -- start/stop/restart the service in RHEL/CentOS 7

So useful! Run the systemd command to manage the Linux system!

Ii. SystemD Tool
Use the SystemD initialization tool to start the system. SystemD includes its own configuration and diagnostic tools. The techniques used when using it to handle system startup problems are different from SysVinit.
The SystemD initialization tool has become a default initialization tool in some release versions. Some other release versions include it as a substitute for upstart and SysVinit. Thanks to its compatibility with upstart and SysVinit, the familiar commands and techniques in the releases using these two initialization tools also apply to SystemD. However, to make good use of the new initialization system function, the system administrator also needs to understand the tool and parameters of SystemD.
The main tool used to send commands to SystemD is systemctl, which is a command line program. This tool requires root permission when changing the configuration file or restarting the background program, but some diagnostic commands can be issued even if it is not a root user. If you do not add any parameters when starting this command, you will see the "unit" list of tasks executed during system startup, including attaching and detecting disks, starting background services, and configuring hardware.
The service unit is one of the most important ones. Because it manages background services, the initialization script is generally used to start these services in the release of SysVinit.
Mount and automount are used to mount the file system.
The socket unit is used to create a socket. After the socket is accessed, the other unit is started indirectly using the dependency relationship.
You can use the parameter to allow systemctl to list only a certain type of units, such as all service units:
Systemctl-type = service
SystemD automatically submits the output results to less display. In the list:
The first column is the name of the unit;
The second column indicates whether the definition of the Unit has been correctly loaded by SystemD.
The third column indicates whether the unit is running. If the-a parameter is used, the program displays only units that are not running, that is, units that are installed but not used at startup, it also contains the unit files that fail to be loaded by the boot system.
The fourth column shows the current status: "exited" indicates that the process has been completed without any errors. This situation applies, for example, if the process does not continue running in the background after it is started, for example, when the system is started,/etc/rc is commonly used in SysVinit for compatibility reasons. d/rc. the Service Unit of the local file. "Running" indicates services Running in the background, such as cron, runtime, sshd, and udev.
The fifth column describes the unit. Units marked with "LSB" or "SYSV" have been automatically created by systemd to manage traditional startup scripts.
Services that cannot be started or crash after startup are marked as "failed" in red in the fourth column ". Run the following command to check when the service crashes and what error code is provided after the service program ends:
Systemctl status ntpd. service
Systemctl lists the service units of the logon process (agetty) that contains text terminals. Because SystemD is different from Sysvinit, it manages these processes in the form of service units like managing common background services.

1. SystemD Service Management
Systemctl is-enabled. service # query whether the service is started
Sudo systemctl enable. service # Start the service
Sudo systemctl disable. service # cancel startup
Sudo systemctl start. service # start the service
Sudo systemctl stop. service # stop the service
Sudo systemctl restart. service # restart the service
Sudo systemctl reload. service # reload the service configuration file
Systemctl status. service # query the service running status
Systemctl-failed # displays services that fail to be started

2. Load the boot Module
/Etc/modules-load.d/. conf, equivalent to the MODULES variable in the original rc. conf
The module blacklist is still under/etc/modprobe. d/, such as blacklist. conf:

3. Locale
/Etc/locale. conf, equivalent to LOCALE in the original rc. conf

4. Log Service
Systemd comes with Log service. For more information, see systemd Journal.
You can delete syslog-ng.

5. Host Name
/Etc/hostname, equivalent to the HOSTNAME variable in the original rc. conf

6. Network
Still use the NetworkManager Tool

For more details, please continue to read the highlights on the next page:

1 2 Next Page