Analysis of Linux init system initialization, Part 1: Systemd

Analysis of Linux init system initialization, Part 1: Systemd

In recent years, the init process of Linux has undergone two major evolution, and the traditional sysvinit has gradually faded out of the historical stage. The new UpStart and systemd have their own characteristics, more and more Linux distributions adopt systemd. This article briefly introduces the use and principles of these three init systems. Every Linux system administrator and system software developer should understand them to better manage systems and develop applications. This article is part 1 of the series. It mainly describes the features and usage of systemd.

Introduction and features of Systemd

Systemd is the latest initialization system (init) in Linux. It is designed to overcome the inherent shortcomings of sysvinit and improve the system startup speed. Zooemd and Ubuntu's upstart are competitors and are expected to replace UpStart. In fact, at the time of writing this article, it has been reported that Ubuntu will also adopt systemd as its standard system initialization system.

Many concepts of Systemd are derived from launchd in the Apple Mac OS Operating System. However, launchd is dedicated to the Apple system, so it has not been widely concerned for a long time. Systemd draws on a lot of launchd ideas. Its important features are as follows:

Compatible with SysVinit and LSB init scripts

Systemd is a "new". Many Linux applications have not had time to change it. Like UpStart, systemd introduces new configuration methods and has new requirements for application development. If systemd is used to replace the currently running initialization system, it must be compatible with the existing program. It is difficult for any Linux release to modify all service code in a short time to adopt systemd.

Systemd provides features that are compatible with Sysvinit and LSB initscripts. The existing services and processes in the system do not need to be modified. This reduces the cost of migrating the system to systemd, making it possible to replace the existing initialization system with systemd.

Faster startup speed

Systemd provides more radical parallel startup capabilities than UpStart, and uses socket/D-Bus activation and other technologies to start services. The obvious result is faster startup speed.

To reduce the system startup time, objective of systemd is:

• Start fewer processes as much as possible
• Start more processes in parallel as much as possible

Similarly, UpStart tries to achieve these two goals. UpStart uses an event-driven mechanism. Services can be started only when necessary. This meets the first design goal. In addition, unrelated services can be started in parallel, this also achieves the second goal.

The following figure demonstrates the improvement of UpStart in concurrent startup compared with SysVInit:

Figure 1. Improved SysVinit by UpStart

Suppose there are seven different startup projects, such as JobA and Job B. In SysVInit, each startup project is executed by an independent script, which is called sequentially and serially by sysVinit. Therefore, the total start time is T1 + T2 + T3 + T4 + T5 + T6 + T7. Some tasks have dependencies, such as A, B, C, and D.

While Job E and F are irrelevant to A, B, C, and D. In this case, UpStart can run the task {E, F, (A, B, C, D)} concurrently, reducing the total start time to T1 + T2 + T3.

This undoubtedly increases the system startup concurrency and increases the system startup speed. However, in UpStart, dependent services must be started successively. For example, tasks A, B, (C, D) are executed in serial mode because of dependency.

For example, the Avahi service requires the functions provided by D-Bus. Therefore, Avahi startup depends on D-Bus and UpStart, avahi must wait until the D-Bus is ready to start. Similarly, both lixid and X11 require the HAL service to be started first, and all these services require the syslog service to record logs. Therefore, they must wait for the syslog service to start first. However, httpd has nothing to do with them, so httpd can start concurrently with services such as Avahi.

Systemd can further improve concurrency, even for services that are considered to be mutually dependent and must be serialized, such as Avahi and D-Bus, which can be concurrently started. To achieve the concurrent startup process as shown in:

Figure 2. Concurrent start of systemd

All tasks are concurrently executed, and the total start time is further reduced to T1.

It can be seen that systemd further improves the parallel startup capability than UpStart, greatly accelerating the system startup time.

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!

Systemd provides on-demand startup capabilities

When the sysvinit system is initialized, it starts all the background service processes that may be used. And the system must wait until all services are ready to start before allowing users to log on. This approach has two disadvantages: the first is that the startup time is too long, and the second is the waste of system resources.

Some services may not be used for a long period of time or even during the entire server operation. For example, CUPS and printing services are rarely used on most servers. You may not have imagined that SSHD is rarely accessed on many servers. The time spent on starting these services is unnecessary; similarly, the system resources spent on these services are also a waste.

Systemd can be enabled on demand only when a service is actually requested. When the service ends, systemd can disable it and wait for it to start again when needed.

Systemd uses the Linux Cgroup feature to track and manage the lifecycle of processes

The init system is responsible for tracking and managing the service process lifecycle. It can not only start a service, but also stop the service. This seems nothing special, but when you actually implement it using code, you may find it more difficult to stop the service than you thought at the beginning.

Generally, a service process runs as a daemon in the background. For this reason, the service program sometimes derives twice. In UpStart, you must correctly configure the CT section in the configuration file. In this way, UpStart counts fork system calls to obtain the PID Number of the real genie process. Example 3:

Figure 3. Find the correct pid

If UpStart finds an error and uses p1' as the Pid of the service process, when the service is stopped, UpStart tries to kill p1' process, while the real p1' process continues to run. In other words, the service is out of control.

There are more special cases. For example, a CGI program will be derived twice, thus breaking away from the parent-child relationship with Apache. When the Apache process is stopped, the CGI program continues to run. We hope that after the service is stopped, all the processes started by it will also be stopped.

To deal with such problems, UpStart uses strace to track fork, exit, and other system calls. However, this method is clumsy and lacks scalability. Systemd uses the Linux kernel feature CGroup to complete tracking tasks. When the service is stopped, you can query the CGroup. systemd ensures that all related processes are found to stop the service cleanly.

CGroup has been around for a long time and is mainly used to manage system resource quotas. CGroup provides interfaces similar to file systems for ease of use. When a child process is created, the child process inherits the CGroup of the parent process. Therefore, no matter how the service starts a new sub-process, all these processes will belong to the same CGroup. systemd only needs to traverse the specified CGroup to find all the relevant processes correctly, stop them one by one.

Start mount point and automatic Mount Management

In traditional Linux systems, users can use the/etc/fstab file to maintain a fixed mount point of the file system. These mount points are automatically mounted when the system starts. Once the START process ends, these mount points are guaranteed to exist. These mount points are all file systems that are critical to system operation, such as the HOME directory. Like sysvinit, Systemd manages these mount points so that they can be automatically mounted at system startup. Systemd is also compatible with the/etc/fstab file. You can continue to use this file to manage mount points.

Sometimes users also need dynamic mount points. For example, if they want to access the content of a DVD, they need to temporarily mount the content to access it. When they do not access the CD, the mount point is canceled (umount ), to save resources. Traditionally, people rely on the autofs service to implement this function.

Systemd has built-in automatic mounting service. without the need to install the autofs service, you can directly use the automatic mounting management capability provided by systemd to implement The autofs function.

Implement transactional dependency management

The system startup process is composed of many independent tasks, which may be dependent on each other. For example, mounting an NFS file system must be dependent on the network to work properly. Although Systemd can execute a lot of dependency tasks concurrently to the maximum extent, jobs like "mounting NFS" and "Starting network" still have inherent dependencies, cannot be executed concurrently. For these tasks, systemd maintains a "transaction consistency" concept to ensure that all related services can be started normally without mutual dependencies, so that deadlocks occur.

Able to take snapshots and restore the system

Systemd supports on-demand startup, so the running status of the system changes dynamically, and people cannot accurately know which services the system is currently running. The Systemd snapshot provides the ability to save and restore the running status of the current system.

For example, if the system is currently running services A and B, you can use the systemd command line to create A snapshot of the current system running status. Then stop process A, or make other changes to the system, such as starting A new process C. After these changes, run the snapshot recovery command of systemd to restore the system to the State at the time of snapshot, that is, only services A and B are running. One possible application scenario is debugging. For example, if a server encounters exceptions, you can save the current status as a snapshot to perform any operations, such as stopping the service. After debugging is complete, you can restore the snapshot.

The Snapshot feature is not complete in systemd. It seems that developers are paying special attention to it. Therefore, some reports indicate that it still has some usage problems. Exercise caution when using it.

Log Service

Mongoemd comes with the Log Service journald, which is designed to overcome the shortcomings of the existing syslog service. For example:

• Syslog is not secure and the message content cannot be verified. Each local process can claim to be Apache PID 4711, and syslog will trust and save it to the disk.
• Data is not in a strict format and is very casual. Automated log analyzer needs to analyze human language strings to identify messages. On the one hand, this type of analysis is difficult and inefficient; in addition, changes in the log format will lead to the need to update or even rewrite the analysis code.

Systemd Journal stores all log information in binary format. You can use the journalctl command to view log information. You do not need to write complex and fragile string analysis processing programs on your own.

Systemd Journal has the following advantages:

• Simplicity: less code, less dependency, and minimum abstract overhead.
• Zero maintenance: logs are the core function of the debugging and monitoring system, so they cannot cause problems themselves. For example, you can automatically manage disk space to avoid consuming disk space due to the continuous generation of logs.
• Portability: log files should be available on all types of Linux systems, regardless of the CPU or byte sequence they use.
• Performance: It is very fast to add and browse logs.
• Minimum resource usage: the log data file must be small.
• Unification: Different log storage technologies should be unified to store all records in the same data storage. Therefore, the global context of the log Content is saved and available for future query. For example, after a firmware record is followed by a kernel record, a user State record is generated. It is important that the relationship between the three items will not be lost when they are saved to the hard disk. Syslog saves different information to different files, and it is difficult to determine which entries are related during analysis.
• Scalability: logs can be used in a wide range, from embedded devices to supercomputer clusters.
• Security: log files can be verified, making undetected changes no longer possible.

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

1 2 3 4 Next Page