Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "how to create and modify systemd unit files in the Linux system". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

(1) Overview of unit files

The unit file contains instructions and behavior information for the unit. The systemctl command works with the unit file in the background. In order to do the job well and correctly, the system administrator must be able to edit the unit file manually. It is recommended that the unit files manually created by the system administrator be stored in the / etc/systemd/system/ directory.

The format of the cell configuration file is:

The code is as follows:

Unit_name.type_extension

Here unit_name represents the unit name and type_extension represents the unit type.

The unit file can be placed in a directory as an additional file, for example, to customize the sshd.service service, you can create a sshd.service.d/custom.conf file and make some custom configuration in the file.

Similarly, you can create sshd.service.wants/ and sshd.service.requires/ directories. These directories contain soft connections for sshd service association services, which are either created automatically or manually when the system is installed.

Many unit configuration files can use unit specifiers-wildcard strings that can be dynamically replaced by variables when the unit file is booted. This makes it possible to create some generic unit configuration templates.

(2) understand the unit file structure.

A typical unit file contains three sections:

The [Unit] section contains general options that do not depend on the unit type, these selections provide a unit description, know the unit behavior, and configure the unit and other unit dependencies.

Section [unittype], if the unit has specific type instructions, these instructions are organized together in the unittype section. For example, the service unit file contains the [Service] section, which contains frequently used service configurations.

The [Install] section contains command installation information for systemctlenable or disable.

1) [Unit] section options

Description unit description information, which is output in the systemclstatus command.

The URLs of the Documentation unit document information.

After is defined to start after those units, and this unit starts only after the defined unit is started, unlike the Requires option, the After option does not explicitly activate a specific unit, while the Before option has the opposite function.

Depending on the Requires configuration unit, the units in the Requires option need to be activated together. If one unit fails to start, the other units will not be started.

Wants is much weaker than Requires option dependencies, and if the unit in the list fails to start, it will not affect other units, which is the recommended way to establish custom unit dependencies.

Conflicts defines unit conflict relationships, as opposed to Requires.

2) option when [unittype] type is [Service]

The type of Type configuration unit process at startup and the function that affects execution and association options. The optional keywords are:

Simple default value, the process starts together with the main process of the service

The forking process starts as a child of the service master process, and the parent process exits after full startup.

Oneshot is similar to simple, but the process exits after starting the unit.

Dbus is similar to simple, but only the main process gets the D-BUS name after the unit starts.

Notify is similar to simple, but after the unit starts, a main message is sent out by the sd_notify () function.

Idle is similar to simple in that the binaries of the actual execution process are delayed until the tasks of all units are completed, mainly to avoid mixed service status and shell output.

ExecStart specifies the command or script of the startup unit, and the ExecStartPre and ExecStartPost sections specify scripts that are customized by the user before or after ExecStart. Type=oneshot allows you to specify multiple user-defined commands that you want to execute sequentially.

ExecStop specifies the command or script to execute when the unit stops.

ExecReload specifies that the unit reloads the command or script that is executed.

If the Restart option is allowed, the process exits when the service is restarted, and the systemctl command is used to erase and restart.

If RemainAfterExit sets this selection to true, the service is considered to be active, even if all processes have exited, the default value is false, and this option needs to be configured only when Type=oneshot.

3) [Install] section options

Alias provides an additional name for the unit with spatial separation.

The RequiredBy unit is allowed to run a series of dependent units needed, and the RequiredBy list gets the dependency information from the Require.

The WantBy unit is allowed to run the required weak dependency unit, and Wantby gets the dependency information from the Want list.

Also indicates the unit that is installed or assisted with the unit.

Restrictions on DefaultInstance instance units, this option specifies if the unit is allowed to run the default instance.

4) an example of a postfix service:

The unit file is located in / usr/lib/systemd/system/postifix.service and is as follows:

The code is as follows:

[Unit]

Description=PostfixMailTransportAgent

After=syslog.targetnetwork.target

Conflicts=sendmail.serviceexim.service

[Service]

Type=forking

PIDFile=/var/spool/postfix/pid/master.pid

EnvironmentFile=-/etc/sysconfig/network

ExecStartPre=-/usr/libexec/postfix/aliasesdb

ExecStartPre=-/usr/libexec/postfix/chroot-update

ExecStart=/usr/sbin/postfixstart

ExecReload=/usr/sbin/postfixreload

ExecStop=/usr/sbin/postfixstop

[Install]

WantedBy=multi-user.target

(3) create a custom unit file

The following scenarios require custom unit files:

You want to create your own daemon

Create a second instance of an existing service

Introduce the SysV init script.

On the other hand, it is sometimes necessary to modify existing unit files.

The steps to create a unit file are described below:

1) prepare the execution file of the custom service.

The executable file can be a script or a software provider's program, and if necessary, prepare a PID file for the main process of the custom service to ensure that the PID remains unchanged. You may also need scripts to configure environment variables to ensure that all scripts have executable properties and do not require interaction.

2) create a unit file in the / etc/systemd/system/ directory and ensure that it can only be edited by root users:

The code is as follows:

Touch/etc/systemd/system/name.servicechmod664/etc/systemd/system/name.service

The file does not require execution permissions.

3) Open the name.service file and add the service configuration. How to configure various variables depends on the type of service added. Here is an example of a configuration that depends on network services:

The code is as follows:

[Unit]

Description=service_description

After=network.target

[Service]

ExecStart=path_to_executable

Type=forking

PIDFile=path_to_pidfile

[Install]

WantedBy=default.target

4) notify systemd that a new service has been added:

The code is as follows:

Systemctldaemon-reload

Systemctlstartname.service

(4) create an example of emacs.service:

1) create a file and ensure the correct permissions:

The code is as follows:

~] # touch/etc/systemd/system/emacs.service

~] # chmod664/etc/systemd/system/emacs.service

2) add configuration information:

The code is as follows:

[Unit]

Description=Emacs:theextensible,self-documentingtexteditor

[Service]

Type=forking

ExecStart=/usr/bin/emacs--daemon

ExecStop=/usr/bin/emacsclient--eval "(kill-emacs)"

Environment=SSH_AUTH_SOCK=%t/keyring/ssh

Restart=always

[Install]

WantedBy=default.target

3) notify systemd and enable the service:

The code is as follows:

~] # systemctldaemon-reload

~] # systemctlstartemacs.service

(5) an example of creating a second sshd service

1) copy the sshd_config file

The code is as follows:

] # cp/etc/ssh/sshd {,-second} _ config

2) Edit sshd-second_config file, add 22220 port, and PID file:

The code is as follows:

Port22220

PidFile/var/run/sshd-second.pid

If you need to modify other parameters, please read the help.

3) copy the unit file:

The code is as follows:

~] # cp/usr/lib/systemd/system/sshd {,-second} .service

4) Edit the unit file sshd-second.service

Modify description field

The code is as follows:

Description=OpenSSHserversecondinstancedaemon

Add the sshd.service service after the After keyword:

The code is as follows:

After=syslog.targetnetwork.targetauditd.servicesshd.service

Remove sshdkey creation:

The code is as follows:

ExecStartPre=/usr/sbin/sshd-keygen

Remove this line

In the execution script, add the configuration file for the second sshd service:

The code is as follows:

ExecStart=/usr/sbin/sshd-D-f/etc/ssh/sshd-second_config$OPTIONS

The modified sshd-second.service file is as follows:

The code is as follows:

[Unit]

Description=OpenSSHserversecondinstancedaemon

After=syslog.target network.targe tauditd.service sshd.service

[Service]

EnvironmentFile=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd-D-f / etc/ssh/sshd-second_config$OPTIONS

ExecReload=/bin/kill-HUP $MAINPID

KillMode=process

Restart=on-failure

RestartSec=42s

[Install]

WantedBy=multi-user.target

5) if you use SELinux and add a tcp port, the port responsible for the second sshd service will be rejected:

The code is as follows:

~] # semanage port-a-tssh_port_t-p tcp22220

6) set boot and test:

The code is as follows:

~] # systemctl enable sshd-second.service

~] $ssh-p 22220 user@server

Make sure the firewall port is also open.

(6) modify existing unit files

The systemd unit configuration file is saved in the / usr/lib/systemd/system/ directory by default. The system administrator does not recommend modifying the files in this directory directly. The custom files are in the / etc/systemd/system/ directory. If there is a need for extension, you can use the following solution:

Create a directory / etc/systemd/system/unit.d/, this is the most recommended way, you can refer to the initial unit file, through the attachment configuration file to expand the default configuration, the default unit file upgrade will be automatically upgraded and applied.

Copy an original configuration file from / usr/lib/systemd/system/ to / etc/systemd/system/, and modify it. The copied version overwrites the original configuration, which does not add additional configuration packages for scenarios that do not require additional functionality.

If you need to restore to the default configuration file, you only need to delete the configuration file under / etc/systemd/system/. You do not need to restart the machine, and use the following command to apply the changes:

The code is as follows:

Systemctl daemon-reload

The daemon-reload option reloads all unit files and recreates the dependency book, which is used when you need to apply unit file changes immediately. Alternatively, you can use the following command to achieve the same goal:

The code is as follows:

Init q

Also, if you modify a unit file that is running a service, the service needs to be restarted:

The code is as follows:

Systemct lrestart name.service

(7) extend the default unit profile configuration

To extend the default unit file configuration, you need to create a directory under / etc/systemd/system/ and execute a command similar to the following with root:

The code is as follows:

Mkdir/etc/systemd/system/name.service.d

Create a configuration file under the directory you just created, which must end with a .conf file.

For example, create a custom dependency file with the following contents:

The code is as follows:

[Unit]

Requires=new_dependency

After=new_dependency

For another example, you can configure a restart 30 seconds after the main process exits. The configuration example is as follows:

The code is as follows:

[Service]

Restart=always

RestartSec=30

It is recommended to generate only one small file at a time, and each file focuses on only one function, so that the configuration file can be easily removed or linked to the configuration directory of other service pairs.

To apply the changes you just made, use root to do the following:

The code is as follows:

Systemctldaemon-reload

Systemctlrestartname.service

Example: extending the httpd.service service configuration

In order to execute a user-defined script when the httpd service starts, you need to modify the unit configuration file of httpd and perform the following steps: first, create a directory of custom files and custom files:

The code is as follows:

~] # mkdir/etc/systemd/system/httpd.service.d

~] # touch/etc/systemd/system/httpd.service.d/custom_script.conf

Assuming the customization file location is / usr/local/bin/custom.sh, add this information to the custom_script.conf customization script:

The code is as follows:

[Service]

ExecStartPost=/usr/local/bin/custom.sh

Apply changes:

The code is as follows:

~] # systemctldaemon-reload

~] # systemctlrestarthttpd.service

This is the end of the introduction of "how to create and modify systemd unit files in the Linux system". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.