The Systemd of Linux system

Zi Gong asked for benevolence. Zi Yue: "工欲善其事, its prerequisite." The house is the state, the sage of his doctor, the benevolence of his friends. --Confucius (Spring and Autumn), "The Analects and Weiling"

"工欲善其事, its prerequisite"

Master a technology, know its development process is very important, know it, and then know the reason why. To be able to achieve and why the two know, need to understand the entire development process. As we did when we were young, we needed to understand the poet's writing background.

Cut into the topic, understand the development of the Linux system, since the thought can better understand the system, master the system.

　　Systemvinit--> Upstart--> systemd

Introduction and features of SYSTEMD

SYSTEMD is the newest initialization system (init) in Linux, its main design goal is to overcome the inherent shortcomings of sysvinit and improve the system startup speed. Systemd and Ubuntu upstart are rivals and are expected to replace upstart, and in fact, when authors write this article, there is already news that Ubuntu will also use SYSTEMD as its standard system initialization system.

Many of Systemd's concepts stem from the launchdon Apple's MAC OS operating system, but Launchd is dedicated to Apple systems and has long failed to get the attention it deserves. Systemd borrowed a lot of launchd ideas, and its important features are as follows:

Compatible with Sysvinit and LSB init scripts

Systemd is a "new", and many applications on Linux do not have the time to make a corresponding change. Like Upstart, SYSTEMD introduces a new configuration approach, and there are new requirements for application development. If SYSTEMD wants to replace the currently running initialization system, it must be compatible with the existing program. It is difficult for any Linux distribution to modify all of the service code in a short period of time in order to use SYSTEMD.

The SYSTEMD provides features that are compatible with Sysvinit and LSB initscripts. Services and processes that already exist in the system need not be modified. This reduces the cost of migrating the system to SYSTEMD, making it possible for SYSTEMD to replace the existing initialization system.

Faster start-up speed

SYSTEMD provides a more aggressive parallel start-up capability than upstart, using technology such as Socket/d-bus activation to start the service. One obvious result: faster start-up speed.

To reduce system start-up time, Systemd's goal is to:

• Start fewer processes as much as possible
• Try to start more processes in parallel

In the same vein, upstart is trying to achieve these two goals. Upstart uses event-driven mechanism, the service can be temporarily not started, when needed to trigger its start through events, which is in line with the first design goal; In addition, irrelevant services can be started in parallel, which also achieves the second goal.

The following figure shows an improvement in the concurrent startup of upstart with respect to Sysvinit:

Suppose there are 7 different startup projects, such as Joba, Job B, and so on. In Sysvinit, each startup project is owned by a separate script, which is called sequentially and serially by Sysvinit. So the total start time is t1+t2+t3+t4+t5+t6+t7. Some of these tasks have dependencies, such as A,b,c,d.

and Job E and F are not related to a,b,c,d. In this case, upstart can run the task {e,f, (a,b,c,d)} concurrently, reducing the total startup time to T1+T2+T3.

This undoubtedly increases the parallelism of the system startup, thus improving the system boot speed. However, in upstart, the service that has dependencies must be started successively. For example, the task, A, B, (c,d) because there is a dependency, so in this part, or serial execution.

　　SYSTEMD can further improve concurrency, even for services that upstart believe to be interdependent and must be serial, to implement the concurrent boot process as shown:

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

The systemd can be seen to further improve the parallel start-up capability and greatly accelerate the system startup time.

SYSTEMD provides on-demand start-up capability

When the Sysvinit system is initialized, it will start running all of the background service processes that may be used. And the system must wait until all services are ready before the user is allowed to log on.                    This approach has two drawbacks: first, the startup time is too long, followed by the waste of system resources.

Some services are likely to be unused for a long period of time, even when the entire server is running. For example, CUPS, the print service is rarely really used on most servers. You may not have imagined that SSHD is rarely actually accessed on many servers. The time spent on initiating these services is unnecessary, and the system resources spent on these services are also wasteful.

SYSTEMD can provide the ability to start on demand and start it only when a service is actually requested. When the service is finished, SYSTEMD can close it and wait for the next time it needs to start again.

SYSTEMD uses the Cgroup feature of Linux to track and manage the lifecycle of a process

An important responsibility for the INIT system is to track and manage the lifecycle of the service process. Not only can it start a service, but it must also be able to stop the service. This may seem like nothing special, but when it comes to real code implementation, you might find that stopping a service is more difficult than it was at first.

The service process typically runs in the background as a daemon (daemon), which sometimes derives (forks) two times. In upstart, the expect section needs to be configured correctly in the configuration file. This upstart the PID number of the true sprite process by counting the fork system calls . The example shown above is 3:

If upstart is wrong, P1 ' as the Pid of the service process, then when the service is stopped, upstart will attempt to kill the P1 ' process, while the real P1 ' process will continue to execute. In other words, the service is out of control.

There are more special situations. For example, a CGI program derives two times, thus leaving the parent-child relationship with Apache. When the Apache process is stopped, the CGI program continues to run. And we want the service to stop, and all the related processes it started are also stopped.

To deal with such problems, Upstart uses Strace to track system calls such as fork, exit, but this approach is clumsy and lacks extensibility. Systemd uses the features of the Linux kernel, which is CGroup, to accomplish the task of tracking . when the service is stopped, querying CGROUP,SYSTEMD ensures that all related processes are found, thus cleanly stopping the service.

CGroup has been there for a long time, it is mainly used to achieve system resource quota management. CGroup provides a file-system-like interface for ease of use. When a process creates a child process, the child process inherits the CGroup of the parent process. So no matter how the service starts a new subprocess, all of these related processes will belong to the same cgroup,systemd simply traverse the specified CGroup to correctly find all the relevant processes and stop them one by one.

Manage to start mount point and Auto Mount

In traditional Linux systems, users can use/etc/fstab files to maintain fixed file system mount points. These mount points are automatically mounted during system boot, and once the boot process is complete, these mount points are guaranteed to be present. These mount points are file systems that are critical to the operation of the system, such as the HOME directory. Like Sysvinit, Systemd manages these mount points so that they can be mounted automatically when the system starts. SYSTEMD is also compatible with/etc/fstab files, and you can continue to use the file to manage mount points.

Sometimes users also need dynamic mount points, such as when they intend to access the contents of the DVD, to temporarily mount to access the contents of it, while not accessing the disc when the mount point is canceled (Umount), in order to conserve resources. Traditionally, people rely on AUTOFS services to implement this function.

　　SYSTEMD built-in automatic Mount service , no additional installation of AUTOFS services, you can directly use the SYSTEMD provides automatic mount management capabilities to achieve autofs functions.

Implementing Transactional Dependency Management

The system startup process is made up of a lot of independent work, which may have dependencies between them, such as mounting an NFS file system that relies on the network to work properly. Systemd Although it is possible to perform many dependent tasks with maximum concurrency, work such as "Mount NFS" and "Start Network" is inherently dependent and cannot be executed concurrently. For these tasks,Systemd maintains a "transactional consistency" concept that ensures that all related services can be started properly without the dependency of a deadlock situation .

Ability to snapshot and recover systems

SYSTEMD supports on-demand startup, so the system's operating state is dynamically changing, and people cannot accurately know what services are currently running on the system. The Systemd snapshot provides the ability to save and restore the current system running state.

For example, the system is currently running services A and B, you can use the SYSTEMD command line to create a snapshot of the current system health. Then either stop process A, or do any other changes to the system, such as starting a new process C. After these changes, run the systemd Snapshot Recovery command to immediately restore the system to the state of the snapshot moment, that is, only service A, B is running. One possible scenario is debugging: For example, the server has some exceptions, in order to debug the user to save the current state as a snapshot, and then can do any action, such as stop service and so on. When debugging is complete, restore the snapshot.

This snapshot feature is currently not perfect in systemd, and it seems that developers are not particularly concerned about it, so there are reports that it still has some use problems, and the use of fashion needs to be cautious.

Log service

Systemd comes with the log service Journald, which is designed to overcome the shortcomings of existing syslog services. Like what:

• The syslog is not secure and the contents of the message cannot be verified. Each local process can claim to be Apache PID 4711, and the syslog is believed and saved to disk.
• The data is not strictly formatted and very casual. Automated log analyzers need to parse human language strings to identify messages. On the one hand, this kind of analysis is difficult and inefficient; In addition, the change in log format causes the parsing code to be updated or even rewritten.

SYSTEMD Journal saves all log information in binary format, and the user uses the Journalctl command to view the log information. You don't have to write your own complex, fragile string analysis handlers.

The advantages of SYSTEMD Journal are as follows:

• Simplicity: Less code, less reliance, and minimal abstraction overhead.
• 0 Maintenance: The log is the core function of the debugging and monitoring system, so it can no longer produce problems. For example, automatically manage disk space to avoid running out of disk space due to continuous log generation.
• Portability: Log files should be available on all types of Linux systems, regardless of the CPU or byte order it uses.
• Performance: Adding and browsing logs is fast.
• Minimum Resource usage: Log data files need to be small.
• Unify: A variety of different log storage technologies should be unified to keep all the logged events in the same datastore. Therefore, the global context of the log content is saved and can be queried later. For example, a firmware record usually follows a kernel record, and eventually a user-state record. It is important that the relationship between the three is not lost when saved to the hard disk. Syslog saves different information to different files, and it is difficult to determine which entries are relevant when analyzing.
• Extensibility: Logs can be used in a wide range of applications, from embedded devices to supercomputer clusters to meet demand.
• Security: Log files can be verified so that undetectable modifications are no longer possible.

See

Http://www.ibm.com/developerworks/cn/linux/1407_liuming_init3/index.html

The Systemd of Linux system