Practical Guide to Writing Systemd Service in Linux System

Publish: 2020-03-23 | Modify: 2020-03-27

Systemd services are unit configuration files that end with .service, used to control or monitor processes controlled or supervised by Systemd. In simple terms, they are used to run programs in the background as daemons. Systemd is widely used in newer versions of RHEL, SUSE Linux Enterprise, CentOS, Fedora, and openSUSE, replacing the old service manager.

Systemd

Getting Started

The content of a Systemd service is mainly divided into three parts: the definition of the control unit, the definition of the service, and the installation section. The services are located in the /etc/systemd/system directory (system services are located in /usr/lib/systemd/system), and they are unit configuration files that end with .service. In this article, we will use the example of creating an nginx service. Assuming you have already compiled and installed nginx, we will now create an nginx service.

# Create an nginx.service file
vi /etc/systemd/system/nginx.service

The content should be as follows:

[Unit]
Description=Nginx - high performance web server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop

[Install]
WantedBy=multi-user.target

Use the command systemctl daemon-reload to load the nginx service that was just created. This way, we can manage nginx using Systemd. The commands are as follows:

# Start nginx
systemctl start nginx
# Reload nginx
systemctl reload nginx
# Stop nginx
systemctl stop nginx
# Restart nginx
systemctl restart nginx
# Enable autostart on boot
systemctl enable nginx
# Disable autostart on boot
systemctl disable nginx

Define Control Unit [Unit]

From the example above, we can see that the Unit section looks like this:

[Unit]
Description=Nginx - high performance web server
After=network.target
  • Description: Represents the description of the entire unit, which can be filled in as needed.
  • Before/After: Specifies the startup order.
  • network.target represents having a network, and network-online.target represents a connected network.

Define the Service [Service]

In the Service section, the content of the service is as follows:

[Service]
Type=forking
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
  • Type: The type of the service, and the differences between various types are as follows:
    • simple: This is the default and simplest type of service. It means that the started program is the main program, and if this program exits, everything stops.
    • forking: This is the startup method used by standard Unix daemons. After starting the program, it calls the fork() function, sets up the necessary communication channels, and then the parent process exits, leaving behind the daemon's child process.
    • oneshot: This is suitable for tasks or commands that are executed only once. After it completes, there will be no traces left. Because there are no traces left after this type of service runs, we often need to use RemainAfterExit=yes. This means that even if there is no process, Systemd still considers the service to have started successfully. Only this type of service supports multiple commands, separated by ;, and line breaks can be represented by \.
    • dbus: This program needs to acquire a piece of DBus space when it starts, so it needs to be used together with BusName=. Only when it successfully acquires the DBus space, will the programs that depend on it be started.
  • ExecStart: The command to be executed when the input command is start. The program started by this command must use an absolute path. For example, you must use /sbin/arp instead of directly using arp with an environment variable.
  • ExecStop: The command to be executed when the input command is stop. The same requirements as above apply.
  • ExecReload: This is not mandatory. If it is not written, your service will not support the restart command. ExecStart and ExecStop are mandatory.

In fact, there are more parameters in the service section. Here are some commonly used parameters:

  • User: Specifies the user to run as.
  • Group: Specifies the group to run as.
  • WorkingDirectory: The working directory of the process, which means that it will switch to this directory before execution.

Install the Service [Install]

In the example above, the installation section looks like this:

[Install]
WantedBy=multi-user.target
  • WantedBy: Specifies who loads the service, usually set to multi-user.target.

Conclusion

Systemd Service is a better way to replace the scripts under /etc/init.d/. It allows flexible control over when to start services and generally does not cause the system to fail to start and enter emergency mode. So if you want to set up something to start on boot, you can try writing a Systemd service. Of course, the prerequisite is that the Linux distribution you are using supports it.

This article is partially referenced from: How to write a Systemd service


Comments