Systemd
Last updated
Last updated
This approach has two drawbacks.
First, the startup time is long. The init process is a serial start, and the next process will be started only after the previous process is started.
The second is the startup script is complicated. The init process just executes the startup script, no matter what else. Scripts need to handle various situations themselves, which often makes the scripts very long.
Systemd was born to solve these problems. It is designed to provide a complete solution for system startup and management.
With Systemd, you don't need to use init again. Systemd replaces initd and becomes the first process of the system (PID equals 1), and other processes are its child processes.
The advantages of Systemd are that they are powerful and easy to use. The disadvantage is that the system is huge and complex. In fact, there are still many people who oppose Systemd, on the grounds that it is too complex and strongly coupled with the rest of the operating system, violating the "keep simple, keep stupid" Unix philosophy.
Systemd is not a command, but a set of commands that cover all aspects of system management.
Systemctl is the main command of Systemd for managing systems
The systemd-analyze command is used to view the startup time.
The hostnamectl command is used to view information about the current host.
The localectl command is used to view localization settings.
Systemd can manage all system resources. Different resources are collectively referred to as Units.
Units are divided into 12 types.
Service unit：系统服务
Target unit：多个 Unit 构成的一个组
Device Unit：硬件设备
Mount Unit：文件系统的挂载点
Automount Unit：自动挂载点
Path Unit：文件或路径
Scope Unit：不是由 Systemd 启动的外部进程
Slice Unit：进程组
Snapshot Unit：Systemd 快照，可以切回某个快照
Socket Unit：进程间通信的 socket
Swap Unit：swap 文件
Timer Unit：定时器
The systemctl list-units command can view all Units of the current system.
In addition to the status command, systemctl also provides a simple method for three query states, mainly for use in the internal judgment statements of the script.
There is a dependency between Units: A depends on B, which means that Systemd will start B when it starts A.
The systemctl list-dependencies command lists all the dependencies of a Unit.
Among the output of the above command, some dependencies are of the Target type (see below), and the default is not expanded. If you want to expand Target, you need to use the --all parameter.
5.1 Overview
Each Unit has a configuration file that tells Systemd how to start the Unit.
By default, Systemd reads the configuration file from the directory /etc/systemd/system/. However, most of the files stored inside are symbolic links, pointing to the directory /usr/lib/systemd/system/, where the real configuration files are stored.
The systemctl enable command is used to establish a symbolic link relationship between the two directories above.
If the boot file is set to boot, the systemctl enable command is equivalent to activating the boot. Correspondingly, the systemctl disable command is used to revoke the symbolic link relationship between the two directories, which is equivalent to canceling the boot.
The suffix name of the configuration file is the type of the unit, such as sshd.socket. If omitted, Systemd defaults to .service, so sshd is interpreted as sshd.service.
This list shows the status of each profile, for a total of four.
enabled：Launch link has been established
disabled：Did not create a launch link
static：This configuration file does not have an [Install] section (cannot be executed) and can only be used as a dependency on other configuration files.
masked：The configuration file is forbidden to create a launch link
Note that it is not clear from the status of the configuration file that the Unit is running. This must be done with the systemctl status command mentioned earlier.
Once the configuration file is modified, let SystemD reload the configuration file and restart it, otherwise the modification will not take effect.
The [Unit] block is usually the first block of the configuration file that defines the metadata for the Unit and the relationship to other Units. Its main fields are as follows.
Description：Short description
Documentation：Document Address
Requires：Other Units that the current Unit depends on. If they are not running, the current Unit will fail to start.
Wants：Other Units that match the current Unit, if they are not running, the current Unit will not start failing.
BindsTo：Similar to Requires, if the Unit specified by it exits, it will cause the current Unit to stop running.
Before：If the Unit specified by this field is also to be started, it must be started after the current Unit.
After：If the Unit specified by this field is also to be started, it must be started before the current Unit.
Conflicts：The Unit specified here cannot be run simultaneously with the current Unit.
Condition：The condition that the current Unit must be run, otherwise it will not run.
Assert：The condition that the current Unit must be run, otherwise it will fail to start.
[Install] is usually the last block of the configuration file, used to define how to start, and whether to boot. Its main fields are as follows.
WantedBy: Its value is one or more Targets. The current Unit activation (enable) symbolic link will be placed in the /etc/systemd/system directory under the subdirectory of the Target name + .wants suffix.
RequiredBy: Its value is one or more Targets. When the current Unit is activated, the symbolic link will be placed in the /etc/systemd/system directory under the subdirectory of the Target name + .required suffix.
Alias: Alias that the current Unit can be used to start
Also: Other Units that will be activated at the same time when Unit is activated (enable)
The [Service] block is used for the configuration of the Service. Only the Unit of the Service type has this block. Its main fields are as follows.
Type: Defines the behavior of the process at startup. It has the following values.
Type=simple: default value, execute the command specified by ExecStart, start the main process
Type=forking: Create a child process from the parent process in fork mode. After the creation, the parent process will immediately exit.
Type=oneshot: One-time process, Systemd will wait for the current service to exit, and then continue to execute
Type=dbus: The current service is started by D-Bus
Type=notify: After the current service is started, Systemd will be notified, and then continue to execute.
Type=idle: The current service will run if other tasks are executed. ExecStart: Command to start the current service
ExecStartPre: Command executed before starting the current service
ExecStartPost: Command executed after starting the current service ExecReload: Command executed when restarting the current service
ExecStop: Command executed when the current service is stopped ExecStopPost: Stops commands executed after their service
RestartSec: Number of seconds to automatically restart the current service interval
Restart: defines what circumstances Systemd will automatically restart the current service, possible values include always (always restart), on-success, on-failure, on-abnormal, on-abort, on-watchdog
TimeoutSec: Defines the number of seconds Systemd waits before stopping the current service Environment: Specify environment variables
When you start your computer, you need to start a large number of Units. If you start each time, it is obviously inconvenient to write out which Units are needed for this startup. The solution for Systemd is Target.
Simply put, Target is a Unit group with many related Units. When a Target is started, Systemd will start all the Units inside. In this sense, the concept of Target is similar to a "state point". Starting a Target is like starting up to a certain state.
In the traditional init startup mode, there is a concept of RunLevel, which is similar to the role of Target. The difference is that RunLevel is mutually exclusive, it is not possible to start multiple RunLevels at the same time, but multiple Targets can be started at the same time.
The correspondence between Target and traditional RunLevel is as follows.
The main differences between it and the init process are as follows.) The location of the configuration file, the configuration file of the previous init process is /etc/inittab, and the configuration files of various services are stored in the /etc/sysconfig directory. The current configuration file is mainly stored in the /lib/systemd directory, and the changes in the /etc/systemd directory can override the original settings.
The default RunLevel (set in the /etc/inittab file) is now replaced by the default Target, located in /etc/systemd/system/default.target, usually symbolically linked to graphical.target (graphical interface) or multi-user .target (multi-user command line).
The location of the startup script, previously in the /etc/init.d directory, symbolically linked to different RunLevel directories (such as /etc/rc3.d, /etc/rc5.d, etc.), now stored in /lib/ Systemd/system and /etc/systemd/system directories.
The location of the configuration file. The configuration file of the previous init process is /etc/inittab. The configuration files of various services are stored in the /etc/sysconfig directory. The current configuration file is mainly stored in the /lib/systemd directory, and the changes in the /etc/systemd directory can override the original settings.
Systemd centrally manages the startup logs for all Units. The advantage is that you can view all logs (kernel logs and application logs) with just one command of journalctl. The configuration file for the log is /etc/systemd/journald.conf.
Journalctl is powerful and has a lot of usage.
