SYSTEMD Introductory Tutorial: The actual combat chapter

SYSTEMD Introductory Tutorial: The actual combat chapter

The previous article, introduced the main command of SYSTEMD, this article mainly describes how to use SYSTEMD to manage our services, as well as the meaning of the various;

First, start the boot

For those who support SYSTEMD software, the installation will automatically add a configuration file in the/usr/lib/systemd/system directory, if you want the software to boot, execute the following command (in the case of Httpd.service).

$ sudo systemctl enable httpd

The above command is equivalent to adding a symbolic link to the/etc/systemd/system directory, pointing to the Httpd.service file inside the/usr/lib/systemd/system.

This is because SYSTEMD only executes the configuration files in the/etc/systemd/system directory when booting. This also means that if you put the modified configuration file in the directory, you can achieve the effect of overwriting the original configuration.

Second, start the service

After setting up the boot, the software does not start immediately and must wait until the next boot. If you want to run the software now, execute the systemctl start command.

$ sudo systemctl start httpd

After executing the above command, it is possible to start a failure, so use the Systemctl status command to see the status of the service.

$ sudo systemctl status httpdhttpd.service-the Apache HTTP Server   loaded:loaded (/usr/lib/systemd/system/httpd.ser Vice Enabled)   active:active (running) since gold 2014-12-05 12:18:22 JST; 7min ago Main pid:4349 (httpd)   Status: "Total requests:1; Current requests/sec:0; Current traffic:   0 b/sec "   CGroup:/system.slice/httpd.service           ├─4349/usr/sbin/httpd-dforeground           ├─4350/usr/sbin/httpd-dforeground           ├─4351/usr/sbin/httpd-dforeground           ├─4352/usr/sbin/httpd-dforeground           ├─4353/usr/sbin/httpd-dforeground           └─4354/usr/sbin/httpd-dforeground12 Month 05 12:18:22 Localhost.localdomain Systemd[1]: Starting the Apache HTTP Server ... December 12:18:22 localhost.localdomain systemd[1]: Started the Apache HTTP server.12 month 12:22:40 localhost.localdomain sys TEMD[1]: Started the Apache HTTP Server.

The above output has the following meanings:

Loaded: Configuration file location, set to boot active line: Indicates running main PID line: main process Idstatus Line: The current state cgroup block of software provided by the app itself (here is httpd): All child process log blocks applied: Log of the app

Third, stop the service

To terminate a running service, you need to execute the systemctl Stop command.

$ sudo systemctl stop Httpd.service

Sometimes, the command may not respond and the service cannot be stopped. This is the time to "kill the process" and send a kill signal to the running process.

$ sudo systemctl kill Httpd.service

Also, restart the service to execute the systemctl restart command.

$ sudo systemctl restart Httpd.service

Iv. Read the configuration file

How a service is started, is determined entirely by its configuration file. Here's a look at what the configuration file contains.

As mentioned earlier, the configuration files are mostly placed in the/usr/lib/systemd/system directory or in the/etc/systemd/system directory. Once the configuration file is found, open it with a text editor.

The Systemctl Cat command can be used to view the configuration file, as an example of the Sshd.service file, which is the role of starting an SSH server for other users to log on SSH.

$ systemctl Cat sshd.service[unit]description=openssh Server DAEMONDOCUMENTATION=MAN:SSHD (8) Man:sshd_config (5) after =network.target sshd-keygen.servicewants=sshd-keygen.service[service]environmentfile=/etc/sysconfig/ sshdexecstart=/usr/sbin/sshd-d $OPTIONSExecReload =/bin/kill-hup $MAINPIDType =simplekillmode=processrestart= On-failurerestartsec=42s[install]wantedby=multi-user.target

As you can see, the configuration file is divided into chunks, each containing several key-value pairs, which in turn explain the contents of each chunk.

v. [UNIT] BLOCK: Startup sequence and Dependencies

The Description field of the unit block gives a simple description of the current service, and the documentation field gives the document location.

The next setup is the boot order and dependency, which is more important.

After field: Indicates that if network.target or sshd-keygen.service need to be started, then sshd.service should start after them.
Accordingly, there is also a before field that defines which services sshd.service should start before.

Note that the after and before fields only involve the boot order and do not involve dependencies.

For example, a WEB application requires a PostgreSQL database to store data. In a configuration file, it is defined only to be started after PostgreSQL, and no dependent PostgreSQL is defined. Once on-line, PostgreSQL needs to be restarted for some reason, and the Web app will not be able to establish a database connection while the service is stopped.

To set up dependencies, you need to use the wants field and the requires field.

Wants field: Indicates that there is a "weak dependency" relationship between Sshd.service and Sshd-keygen.service, that is, if "Sshd-keygen.service" fails to start or stops, it does not affect sshd.service execution.
The requires field represents a "strong dependency" relationship, meaning that if the service fails to start or exits abnormally, sshd.service must also exit.

Note that the wants field and the requires field only involve dependencies, regardless of the boot order, which is started by default.

Vi. [Service] Block: Startup behavior

Service blocks define how the current service is started.

6.1 Start Command

Many software have their own environment parameter files, which can be read in the Environmentfile field.

Environmentfile field: Specifies the environment parameter file for the current service. The Key=value key-value pair inside the file can be obtained in the current configuration file in the form of $key.

In the above example, the environment parameter file for sshd is/etc/sysconfig/sshd.

The most important field in the configuration file is Execstart.

Execstart field: Defines the command to execute when the process is started.

In the above example, starting sshd, the command executed is/usr/sbin/sshd-d $OPTIONS, where the variable $options is from the environment parameter file specified in the Environmentfile field.

Similar to the function, there are the following fields.

Execreload field: command to restart the Service execstop field: command executed when the service is stopped execstartpre field: The command to execute before starting the Service Execstartpost field: The command to execute after the service is started Execstoppost field: After the service is stopped. Command

Take a look at the example below.

[Service] Execstart=/bin/echo Execstart1execstart=execstart=/bin/echo Execstart2execstartpost=/bin/echo post1ExecStartPost= /bin/echo Post2

The above configuration file, the second line Execstart set to null, is equal to the cancellation of the first row of the settings, the result is as follows.

Execstart2post1post2

All startup settings can be preceded by a conjunction number (-), which means "suppress error", that is, when an error occurs, does not affect the execution of other commands. For example, ENVIRONMENTFILE=-/ETC/SYSCONFIG/SSHD (note the conjunction number after the equal sign) means that even if the/etc/sysconfig/sshd file does not exist, it will not throw an error.

6.2 Startup Type

The Type field defines the startup types. The values it can set are as follows.

Simple (default): The process initiated by the Execstart field will start as a fork (), and the parent process will exit and the child process will become the main process oneshot: similar to simple, but only once, SYSTEMD will wait for it to execute before starting other services Dbus: similar to simple, but will wait for the D-bus signal to start notify: Similar to simple, after the start of the notification signal will be issued, and then Systemd to start other services idle: similar to Simple , but the service will not start until all other tasks have been executed. One use case is to let the output of the service not be mixed with the output of other services

Here is an example of a oneshot, when the laptop starts, to turn off the touchpad, the configuration file can be written like this.

[Unit] Description=switch-off touchpad[service]type=oneshotexecstart=/usr/bin/touchpad-off[install]wantedby= Multi-user.target

The above configuration file, the startup type set to OneShot, indicates that the service runs once enough and does not require long-term operation.

If you close later, and you want to open it sometime in the future, the configuration file is modified as follows.

[Unit] Description=switch-off Touchpad[service]type=oneshotexecstart=/usr/bin/touchpad-off startExecStop=/usr/bin/ Touchpad-off Stopremainafterexit=yes[install]wantedby=multi-user.target

In the above configuration file, the Remainafterexit field is set to Yes, indicating that the service remains executing after the process exits. In this case, once the service is stopped using the Systemctl Stop command, the command specified by Execstop executes, thereby re-opening the touchpad.

6.3 Restart Behavior

There are fields in the service block that define the restart behavior.

Killmode field: Defines how SYSTEMD stops the sshd service.

In this example, Killmode is set to process, which means that only the main process is stopped and no sshd sub-processes are stopped, that is, the SSH session opened by the child process remains connected. This setting is less common, but it is important for sshd, or you can stop the service and kill it with your open SSH session.

The value of the Killmode field can be set as follows.

Control-group (default): All child processes in the current control group will be killed process: kill only the main process mixed: The main process will receive the SIGTERM signal, the child process receives the SIGKILL signal none: No process will be killed, just perform the service The Stop command.

Next is the restart field.

Restart field: Defines how the SYSTEMD restarts after the sshd exits.
In the above example, restart is set to On-failure, which indicates that any unexpected failure will restart the sshd. If sshd stops normally (such as executing the SYSTEMCTL Stop command), it does not restart.

The value of the Restart field can be set as follows.

No (default): Does not restart after exiting the on-success: only when the normal exit (exit status code is 0), will restart On-failure: Abnormal exit (exit status code not 0), including signal termination and timeout, To restart the On-abnormal: Only the signal is signaled and timed out to restart the On-abort: only if a signal that has not been captured is terminated, the On-watchdog is restarted: Timeout exited before restarting always: no matter what the reason for the exit, the restart

For Daemons, the recommended setting is On-failure. For those services that allow for an error exit, you can set it to On-abnormal.

Finally, the Restartsec field.

Restartsec field: Indicates the number of seconds to wait before SYSTEMD restarts the service. The above example is set to wait 42 seconds.

Vii. [Install] Block

Install block, which defines how the configuration file is installed, that is, how to boot.

Wantedby field: Indicates the Target at which the service resides.

Target means a service group that represents a set of services. Wantedby=multi-user.target means that the Target of sshd is multi-user.target.

This setting is important because when you execute the systemctl enable Sshd.service command, a symbolic link to sshd.service is placed in the/etc/systemd/ The Multi-user.target.wants subdirectory under the system directory.

The SYSTEMD has a default boot Target.

$ systemctl Get-defaultmulti-user.target

The result above indicates that the default boot Target is multi-user.target. All the services in this group will boot up. This is why the Systemctl enable command can be set to boot.

The Systemctl list-dependencies command and the Systemctl Isolate command are also useful when using Target.

# View all services included in Multi-user.target $ systemctl list-dependencies multi-user.target# Switch to another target# Shutdown.target is shutdown status $ sud o Systemctl Isolate Shutdown.target

In general, there are two commonly used Target: One is Multi-user.target, which indicates the multi-user command line state, and the other is Graphical.target, which represents the graphical user state, which relies on multi-user.target. Official documents have a very clear Target dependency diagram.

viii. Target configuration file

Target also has its own configuration file.

$ systemctl Cat Multi-user.target[unit]description=multi-user systemdocumentation=man:systemd.special (7) Requires= Basic.targetconflicts=rescue.service Rescue.targetafter=basic.target Rescue.service Rescue.targetAllowIsolate=yes

Note that the Target configuration file does not have a start command.

In the output above, the main field has the following meanings.

Requires field: Requires Basic.target to run together. Conflicts field: conflict field. If Rescue.service or Rescue.target are running, Multi-user.target cannot run and vice versa. After: Indicates that Multi-user.target is started after Basic.target, Rescue.service, Rescue.target, if they have started. Allowisolate: Allows you to switch to Multi-user.target using the Systemctl isolate command.

Nine, after modifying the configuration file restart

After you modify the configuration file, you need to reload the configuration file and then restart the related service.

# reload config file $ sudo systemctl daemon-reload# restart related services $ sudo systemctl restart Foobar

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better: http://www.linuxprobe.com/

SYSTEMD Introductory Tutorial: The actual combat chapter