Brief analysis of Linux initialization init system, part 3rd: Systemd

Source: Internet
Author: User
Tags call back change settings sessions syslog openssh server

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 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 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 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:

Figure 1. The improvement of upstart 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.

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 Systemd

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:

Figure 3. Find the correct PID

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.

Back to top of page

Concept of the basic concept unit of SYSTEMD

There 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.

  • Service: Represents a background services process, such as mysqld. This is the most commonly used category.
  • Sockets: This class of Hive encapsulates the system and a socket in the Internet. Now, SYSTEMD supports Af_inet, AF_INET6, Af_unix sockets for streaming, datagram, and sequential packets. Each socket hive has a corresponding service hive. The corresponding service starts when the first connection enters the socket (for example: Nscd.socket starts nscd.service after a new connection).
  • Device: This class of hives encapsulates a device that exists in the Linux device tree. Each device marked with Udev rules will appear as a device hive in Systemd.
  • Mount: This class of hives encapsulates a mount point in the file system hierarchy. SYSTEMD will monitor and manage this mount point. For example, it can be mounted automatically at startup, and can be uninstalled automatically under certain conditions. SYSTEMD will convert the entries in the/etc/fstab to mount points and process them at boot time.
  • AutoMount: This class of Hive encapsulates a self-mounting point in the system hierarchy. Each self-mounting hive corresponds to a Mount hive, and when the automatic mount point is accessed, SYSTEMD performs the mount behavior defined in the mount point.
  • Swap: Similar to mount Hive, the Swap hive is used to manage the swap partition. Users can use swap hives to define swap partitions in the system so that these swap partitions are activated at startup.
  • Target: This type of hive logically groups other hive units. They don't actually do anything themselves, they just reference other hive units. This allows for a unified control of the hive. This makes it possible to implement the concept of runlevel that everyone is already familiar with. For example, to get the system into a graphical mode, you need to run a number of services and configuration commands, which are represented by a single hive, all of which are grouped into one target, which means that the hive needs to be executed all over in order to enter the system running state that the target represents. (Example: Multi-user.target equivalent to running level 5 in a system that traditionally uses SysV)
  • Timer: The timer hive is used to trigger user-defined actions on a timed basis, which replaces traditional timing services such as ATD and Crond.
  • Snapshot: Similar to the target hive, a snapshot is a set of hive. It saves the current running state of the system.

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 relationships

Although 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 transactions

SYSTEMD 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 dependency

There 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 level

SYSTEMD 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 SYSTEMD

As 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 dependencies

The 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 dependencies

D-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 Dependencies

During 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 SYSTEMD

Here 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 Developers

Developers 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 background service process code does not need to perform two derivation to implement the background daemon process, only the main loop of the service itself is implemented.
    • Do not call Setsid (), give SYSTEMD handle
    • It is no longer necessary to maintain PID files.
    • SYSTEMD provides logging capabilities, and the service process only needs to be output to stderr, without the use of syslog.
    • Processing signal SIGTERM, the only correct function of this signal is to stop the current service, do not do other things.
    • The function of the SIGHUP signal is to restart the service.
    • Services that require sockets, do not create sockets on their own and let Systemd pass in sockets.
    • Use the Sd_notify () function to notify the SYSTEMD service of its own state change. In general, it can be called when the service initialization is complete and enters the service-ready state.

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 administrator

The 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:

    • Maintain, track sessions and user logins. As mentioned above, in order to determine whether the shutdown command is feasible, the system needs to know the current user logon situation, if the user logged in from SSH, do not allow the shutdown command, if the ordinary user logged on locally, and the user is the only session in the system, it is allowed to execute the shutdown command; these judgments all require logind Maintains all user sessions and logon situations.
    • Logind is also responsible for counting user sessions for a long time without action, and can perform actions such as hibernation/shutdown.
    • Create CGroup for all processes of the user session. This not only facilitates the statistics of all user sessions related processes, but also enables session-level system resource control.
    • Responsible for the power management of the combination of key processing, such as the user to press the power button to switch the system to sleep state.
    • Multi-seat (multi-seat) management. Today's computers, even a laptop, can provide the computing power that many people use at the same time. Multi-seat is a computer host to manage multiple peripherals, such as two screens and two mouse/keyboard. Seat one uses screen 1 and keyboard 1; seats two use screen 2 and keyboard 2, but they all share a single host. User sessions are free to switch between multiple seats. or when inserting a new keyboard, screen and other physical peripherals, automatically start the GDM user login interface and so on. All of these are multi-seat management content. Consolekit has never implemented this feature, SYSTEMD's logind can support multiple seats.

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 Summary

In the author's view, as a system initialization system, SYSTEMD has the greatest features of two:

    • Surprisingly aggressive concurrent start-up capability, greatly improving the system boot speed;
    • Tracking sub-process with CGroup statistics, clean and reliable.

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

Conclusion

This 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)

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.