In recent years, the Linux system init process has undergone two major evolution, the traditional sysvinit has gradually faded out of the historical stage, the new upstart and systemd each have the characteristics, more and more Linux distribution adopted the SYSTEMD. This article briefly describes the use and rationale of these three init systems, which each Linux system administrator and system software developer should know to better manage systems and develop applications. This article is the 3rd part of the series, mainly on the characteristics and use of systemd.
Introduction and features of SYSTEMDSYSTEMD 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 launchd on 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 scriptsSystemd 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 speedSYSTEMD 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:
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:
Figure 1. The improvement of upstart to SysvinitSuppose 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.
Let's take a few examples where the Avahi service needs D-bus functionality, so Avahi's start depends on D-bus,upstart, and Avahi must wait until D-bus is ready to start. Similarly, both LIVIRTD and X11 require the HAL service to start first, and all of these services require syslog service logging, so they all have to wait for the Syslog service to start up first. However, httpd is not related to them, so httpd can be started concurrently with services such as Avahi.
SYSTEMD can further improve concurrency, even for services that upstart believe are interdependent and must be serial, such as Avahi and D-bus, can also be started concurrently. This enables the concurrent startup process as shown:
Figure 2. Concurrent startup of SystemdAll 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 capabilityWhen 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 processAn 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:
Figure 3. Find the correct PIDIf 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 MountIn 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 ManagementThe 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 systemsSYSTEMD 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 serviceSystemd comes with the log service Journald, which is designed to overcome the shortcomings of existing syslog services. Like what:
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:
Back to top of page
Concept of the basic concept unit of SYSTEMDThere are a lot of things you need to do to initialize your system. Need to start a background service, such as starting the SSHD service, need to do configuration work, such as Mount file system. Each step in the process is abstracted by SYSTEMD as a hive, or unit. A service can be thought of as a hive, a mount point is a hive, the configuration of a swap partition is a hive, and so on. SYSTEMD the configuration unit into some of the following different types. However, SYSTEMD is growing fast and new features are increasing. Therefore, the hive type may continue to increase in the near future.
Each hive has a corresponding profile, and the system Administrator's task is to write and maintain these different configuration files, such as a MySQL service corresponding to a mysql.service file. The syntax of this configuration file is very simple, and the user does not need to write and maintain complex system 5 scripts.
Dependent relationshipsAlthough Systemd has removed a lot of startup work from dependencies, they can be started concurrently. However, there are some tasks, there is a natural dependency between them, can not use the "socket activation" (socket activation), D-bus activation and AutoFS three methods to remove the dependency (the three methods for details see the following description). 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 address this type of dependency, dependencies can be defined between SYSTEMD hive units.
SYSTEMD uses the keywords in the hive definition file to describe dependencies between hive. For example, unit a relies on unit B, which can be expressed as "require A" in the definition of Unit B. This way the SYSTEMD will ensure that A and start B is started first.
SYSTEMD transactionsSYSTEMD can guarantee transactional integrity. The SYSTEMD transaction concept differs from the database, primarily to ensure that there are no ring references between multiple dependent hive units. For example, unit A, B, C, if their dependencies are:
Figure 4, the Unit's cyclic dependencyThere is a cyclic dependency, then 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 dependencies between hive: Required is strong dependency, want is weak dependency, Systemd will remove the dependency specified by the wants keyword to see if it can break the loop. If it cannot be repaired, SYSTEMD will error.
Systemd is able to automatically detect and fix such configuration errors, which greatly reduces the administrator's troubleshooting burden.
Target and Run levelSYSTEMD replaces the concept of runlevel with the target, providing greater flexibility, such as you can inherit an existing target and add other services to create your own goals. The following table lists the correspondence between the targets under SYSTEMD and the common runlevel:
Table 1. Sysvinit the corresponding table for the RunLevel and SYSTEMD targets| Sysvinit Run Level | Systemd Target | Notes |
|---|---|---|
| 0 | Runlevel0.target, Poweroff.target | Shut down the system. |
| 1, S, single | Runlevel1.target, Rescue.target | Single-user mode. |
| 2, 4 | Runlevel2.target, Runlevel4.target, Multi-user.target | User-defined/domain-specific runlevel. The default is equal to 3. |
| 3 | Runlevel3.target, Multi-user.target | Multi-user, non-graphical. Users can log on through multiple consoles or networks. |
| 5 | Runlevel5.target, Graphical.target | Multi-user, graphical. Typically, all run Level 3 services plus graphical logins. |
| 6 | Runlevel6.target, Reboot.target | Restart |
| Emergency | Emergency.target | Emergency Shell |
Back to top of page
The concurrent start principle of SYSTEMDAs mentioned earlier, in SYSTEMD, all services are started concurrently, such as Avahi, D-bus, LIVIRTD, X11, and HAL can start at the same time. At first glance, this seems to be a bit of a problem, such as Avahi need syslog service, Avahi and syslog start simultaneously, assuming Avahi start relatively fast, so the syslog is not ready, but Avahi need to log, this will not be a problem?
SYSTEMD's developers carefully examined the nature of the interdependencies between services, and found that the so-called dependencies can be divided into three specific types, each of which can actually be removed from the dependency by the appropriate technology.
One of the concurrent startup principles: Resolving socket dependenciesThe overwhelming majority of service dependencies are socket dependent. For example, service a provides its own service through a socket port S1, and other services need to connect S1 if service A is required. Therefore, if service A is not started, S1 does not exist, and other services will get a startup error. So traditionally, people need to start service A, wait for it to go into a ready state, and start other services that need it. Systemd 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 the S1. If service A is not yet started, the service requests sent to S1 by other processes are actually cached by the Linux operating system, and other processes wait at the request. Once service A is 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 creates a child process, all file descriptor that are opened in the parent process are inherited by the quilt 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, the new child process can inherit the socket as long as the CLOSE_ON_EXEC flag bit is cleared. The socket that the child process sees and the socket created by the parent process are the same system socket, as if the socket was created by the child process itself, without any distinction.
This feature was previously used by a system service called inetd. The INETD process is responsible for monitoring some common socket ports, such as Telnet, when the port has a connection request, INETD starts the telnetd process and passes the connected socket to the new telnetd process for processing. This way, you do not need to start the telnetd process when the system does not have a Telnet client connection. INETD can proxy a lot of network services, so that 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 to pass the socket to the corresponding service process.
Similar to inetd, SYSTEMD is the parent process for all other processes, which can first establish all the required sockets and then pass the socket to the new service process when exec is called, while the new process uses the socket directly for service.
The second principle of concurrent booting: Resolving D-bus dependenciesD-bus is the abbreviation for Desktop-bus, which is a low-latency, low-overhead, high-availability interprocess communication mechanism. It is increasingly used for communication between applications, and also for communication between applications and operating system cores. Many modern service processes use D-bus instead of sockets as inter-process communication mechanisms to provide services externally. For example, the NetworkManager service that simplifies the Linux network configuration interacts with D-bus and other applications or services: The mail client software evolution can obtain changes to the network state through D-bus from the NetworkManager service in order to The corresponding processing.
D-bus supports the so-called "Bus Activation" feature. If service a needs to use service B's D-bus service, and service B is not running, D-bus can start service B automatically when service a requests service B's D-bus. The request from service A is D-bus cached and service a waits for service B to start ready. With this feature, D-bus-dependent services can be used to enable parallel booting.
The third principle of concurrent booting: Resolving file System DependenciesDuring system startup, file system-related activity is the most time consuming, such as mounting the file system, disk checking on the file system (FSCK), disk quota checking, and so on are very time-consuming operations. While waiting for these jobs to complete, the system is in an idle state. Services that want to use the file system seem to have to wait for the file system to initialize before it can be started. But Systemd found that this kind of dependence can also be avoided.
SYSTEMD reference to the design of AutoFS, so that the dependent file system services and the file system itself initialization can work concurrently. AutoFS can monitor that a file system mount point is actually accessed to trigger a mount operation, which is implemented through the support of the kernel Automounter module. For example, when an open () system call is in "/misc/cd/file1",/MISC/CD has not yet performed a mount operation, when the open () call is pending, the Linux kernel notifies 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, when the system starts, SYSTEMD creates a temporary automatic mount point for it. At this time/home real Mount device has not been started well, the real mount operation has not been executed, file system detection has not been completed. However, the processes that depend on the directory can already be started concurrently, and their open () operations are captured by AutoFS built into SYSTEMD, suspending the open () call (sleep state can be interrupted). Then wait for the real mount operation to complete, and after file system detection is complete, SYSTEMD replaces the automatic mount point with the true mount point and makes the open () call back. As a result, services that rely on the file system and the file system itself are implemented concurrently to start.
Of course, the "/" root of the dependency must still be serially executed, because the SYSTEMD itself is also stored in/under, you have to wait for the system root mount check.
However, similar to the home/home mount point, this concurrency can improve the system startup speed, especially when/home is a remote NFS node, or encryption disk, and so on, it takes a long time to be ready, because of the concurrent start, during this time, the system is not completely nothing to do, Instead, you can use this free time to do more of the startup process, which in general shortens the system startup time.
Back to top of page
Use of SYSTEMDHere is a brief introduction to the use of systemd for the different roles of the technician. This article only intends to give a simple description, so that you have a general understanding of the use of SYSTEMD. Specific details too much, that can not be written in a short text, I do not have the ability to be so powerful. Readers are also required to consult the SYSTEMD documentation themselves.
System software DevelopersDevelopers need to know more details about the SYSTEMD. For example, if you are going to develop a new system service, you must know how to make the service managed by SYSTEMD. This requires your attention to the following points:
The writing of the Unit file
For developers, the biggest part of the effort should be to write hive files that define the required units.
For example, a developer who developed a new service program, such as httpd, needs to write a hive file for it so that the service can be systemd managed, similar to upstart's work profile. In this file, you define the command-line syntax for the service to start, as well as dependencies on other services.
In addition, we have learned that Systemd has a wide range of functions, not only for managing services, but also for managing mount points, defining timed tasks, and more. The work is done by editing the corresponding hive file. Here's an example of a few hive files I'm giving you here.
The following is the configuration unit file for the SSH service, the service hive file with the. Service as the file name suffix.
#cat/etc/system/system/sshd.service [Unit] description=openssh Server daemon [service] Environmentfile=/etc/sysconfig/sshd Execstartpre=/usr/sbin/sshd-keygen execstart=/usrsbin/sshd–d $ OPTIONS execreload=/bin/kill–hup $MAINPID killmode=process restart=on-failure restartsec=42s [Install] Wantedby=multi-user.target
The file is divided into three sections. The first one is the [Unit] section, where there is only one descriptive message. The second part is the service definition, where Execstartpre defines the commands that should be run before starting the service; Execstart defines the specific command-line syntax for starting the service. The third part is [Install],wangtedby indicates that the service is required in multi-user mode.
Let's take a look at the Multi-user.target:
#cat multi-user.target [Unit] description=multi-user System documentation=man.systemd.special (7) Requires=basic.target Conflicts=rescue.service rescure.target after=basic.target rescue.service rescue.target AllowIsolate= Yes [Install] Alias=default.target
The Requires definition in the first section indicates that Basic.target must also be started when Multi-user.target is started, and Multi-user.target must stop when Basic.target is stopped. If you continue to view the Basic.target file, you will find that it also specifies that other cells such as Sysinit.target must be started with it. The same sysinit.target will also contain other units. With such a layer-by-layer link structure, all Component Services that need to support multi-user mode will eventually be initialized.
In the [Install] section there is an alias definition, which defines the alias of this unit so that you can use this alias to refer to this unit when you run SYSTEMCTL. The alias here is Default.target, more simple than multi-user.target ...
Also in the/etc/systemd/system directory you can see directories such as *.wants, where the hive file is equivalent to the wants keyword in the [unit] subsection, which is required to start the unit when it starts. For example, you can simply put your own foo.service files into the multi-user.target.wants directory, so that each time it will be started by default.
Finally, let's take a look at the Sys-kernel-debug.mout file, which defines a file mount point:
#cat Sys-kernel-debug.mount[unit]description=debug File systedefaultdependencies=noconditionpathexists=/sys/ Kernel/debugbefore=sysinit.target[mount]what=debugfswhere=/sys/kernel/debugtype=debugfs
This hive file defines a mount point. The Mount hive file has a [Mount] configuration section, which is configured with What,where and Type three data items. This is all necessary to mount the command, and the configuration in the example is equivalent to the following Mount command:
Mount–t Debugfs/sys/kernel/debug Debugfs
The preparation of the hive file requires a lot of learning, and you must refer to the man document included with SYSTEMD for further study. I hope that through the above few small examples, you already understand the role of the hive file and the general wording.
System administratorThe main command-line tool for SYSTEMD is systemctl.
Most administrators should already be familiar with the management of system services and INIT systems, such as service, Chkconfig, and Telinit commands. SYSTEMD also accomplishes the same management tasks, except that the syntax of the command tool Systemctl is different, so it is clear to use tables to compare SYSTEMCTL and traditional system administration commands.
Table 2. Comparison of Systemd command and Sysvinit command| sysvinit Command | Systemd Command | Notes |
|---|---|---|
| Service Foo Start | Systemctl Start Foo.service | Used to start a service (does not restart the existing one) |
| Service Foo Stop | Systemctl Stop Foo.service | Used to stop a service (and not restart the existing one). |
| Service Foo Restart | Systemctl Restart Foo.service | Used to stop and start a service. |
| Service Foo Reload | Systemctl Reload Foo.service | When supported, remount the configuration file without interrupting the wait operation. |
| Service Foo Condrestart | Systemctl Condrestart Foo.service | If the service is running then restart it. |
| Service Foo Status | Systemctl Status Foo.service | Reports whether the service is running. |
| ls/etc/rc.d/init.d/ | Systemctl List-unit-files--type=service | Used to list the services that can be started or stopped. |
| Chkconfig foo on | Systemctl Enable Foo.service | Setting the service to Enabled at the next startup or when other trigger conditions are met |
| Chkconfig foo off | Systemctl Disable Foo.service | Setting the service to disabled at the next startup or when other trigger conditions are met |
| Chkconfig Foo | Systemctl is-enabled Foo.service | Used to check whether a service is configured to be enabled or disabled in the current environment. |
| Chkconfig–list | Systemctl List-unit-files--type=service | Output enabled and disabled for the service under each run level |
| Chkconfig foo–list | Ls/etc/systemd/system/*.wants/foo.service | Use to list which run levels the service is enabled and disabled under. |
| Chkconfig Foo–add | Systemctl Daemon-reload | Used when you create a new service file or change settings. |
| Telinit 3 | Systemctl isolate Multi-user.target (or Systemctl isolate Runlevel3.target OR telinit 3) | Change the maximum user run level. |
In addition to the common uses listed in table 2, system administrators need to be aware of other changes in system configuration and management tasks.
First we understand how SYSTEMD handles power management, and the command is shown in the following table:
Table 3,SYSTEMD Power Management commands| Command | Operation |
|---|---|
| Systemctl reboot | Restarting the machine |
| Systemctl Poweroff | Shutdown |
| Systemctl suspend | Standby |
| Systemctl Hibernate | Dormancy |
| Systemctl Hybrid-sleep | Mixed sleep mode (simultaneously hibernate to hard drive and standby) |
The shutdown is not performed by every logged-on user under any circumstances, and is generally only available to administrators. Under normal circumstances, the system should not allow SSH Telnet users to perform shutdown commands. Otherwise, other users are working, and a user shutting down the system is not good. To solve this problem, traditional Linux systems use Consolekit to track user logins and decide whether to give them permission to shut down. Now Consolekit has been replaced by Systemd's logind.
Logind is not a pid-1 init process. Its role is similar to the upstart session INIT, but it is much more versatile, and it manages almost all user sessions (session) related things. Logind is not only an alternative to Consolekit, it can:
These management functions described above are only part of the SYSTEMD function, in addition, SYSTEMD also responsible for the system other management configuration, such as configuration network, Locale management, management system kernel module loading, etc., completely describe them have exceeded my ability.
Back to top of page
SYSTEMD SummaryIn the author's view, as a system initialization system, SYSTEMD has the greatest features of two:
Moreover, unlike its predecessor, SYSTEMD is more than just an initialization system.
SYSTEMD is an excellent substitute for all the features of Sysvinit, but it is not complacent. Because the init process is so specific to the parent process of all processes in the system, SYSTEMD is well suited to provide functionality that was once provided by other services, such as timed tasks (previously completed by Crond), Session Management (formerly managed by Consolekit/polkit, etc.). Just from the fur of the introduction of this article, SYSTEMD has been a lot of control, but it is still evolving. It will gradually become a multi-functional system environment, able to handle a lot of system management tasks, some people even regard it as an operating system.
The good thing is, this is very helpful for standardizing Linux management! In the past, different Linux distributions used different methods to manage the system and never compromised each other. For example, how to put the system into hibernation, different systems have different solutions, even the same Linux system, there are different methods, such as an interesting discussion: How to hibernate the Ubuntu system, you can use the underlying/sys/power/state interface, you can also use such as Pm-utility and other high-level interfaces. There are so many different ways to do something that is not an interesting thing for a normal user like me. SYSTEMD provides a unified power Management command interface, the meaning of this thing is similar to people all over the world speak unified language, we no longer need to learn a foreign language, how beautiful!
If all Linux distributions incorporate SYSTEMD, system administration tasks can be standardized to a large extent. In addition, SYSTEMD has a great commitment: the interface remains stable and will not be easily altered. For software developers, this is a very thoughtful and moving commitment Ah!
Back to top of page
ConclusionThis series of articles starts with the old but concise and stable sysvinit, and then briefly describes the fresh changes brought about by upstart, and finally sees a new generation of SYSTEMD systems that are ambitious and energetic, gradually dominating all versions of Linux. It's like looking at our world, a generation old, a new generation on the stage with all the spirit sweeping, not shouting out their strongest slogan, the more powerful generation has taken the spotlight and all eyes away. There may be an updated init system after Systemd, let's continue to look forward to ...
Brief analysis of Linux initialization init system, part 3rd: Systemd (RPM)
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
