Practical Guide to Writing Systemd Services in Linux

Systemd services are unit configuration files ending in .service, used to control or monitor processes managed by Systemd. Simply put, they allow programs to run in the background as daemons. Systemd is widely used in newer versions of RHEL, SUSE Linux Enterprise, CentOS, Fedora, and openSUSE to replace the older service manager.

Getting Started

A Systemd service configuration consists of three main parts: the unit definition, the service definition, and the installation section. Service paths are located in the /etc/systemd/system directory (system services reside in /usr/lib/systemd/system). Unit configuration files end with .service. This article uses creating an Nginx service as an example, assuming you have already compiled and installed Nginx manually. Let's create the Nginx service file:

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

The content should look like this:

[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

Run the command systemctl daemon-reload to load the newly created Nginx service. You can now manage Nginx using Systemd with the following commands:

# Start Nginx
systemctl start nginx
# Reload Nginx
systemctl reload nginx
# Stop Nginx
systemctl stop nginx
# Restart Nginx
systemctl restart nginx
# Enable Nginx to start on boot
systemctl enable nginx
# Disable Nginx from starting on boot
systemctl disable nginx

Defining the Unit [Unit]

From the example above, the Unit section looks like this:

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

• Description: Represents the description of the entire unit; you can fill this in as needed.
• Before/After: Specifies the startup order.
• network.target: Indicates that the network is available. network-online.target indicates that a connected network is available.

Defining the Service Body [Service]

The Service body in the example above is:

[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 service. The differences between various types are as follows:
  • simple: The default type. This is the simplest service type, meaning the launched program is the main process. If this program exits, the service stops.
  • forking: The standard Unix Daemon startup method. After launching the program, it calls the fork() function, sets up necessary communication channels, and the parent process exits, leaving the daemon child process.
  • oneshot: Suitable for tasks or commands executed once. Once the service runs, it leaves no trace. Since these services leave no trace after running, we often use RemainAfterExit=yes. This means Systemd considers the service started successfully even if no process exists. Only this type supports multiple commands, separated by ;. Use for line breaks.
  • dbus: This program requires acquiring a DBus space when starting, so it must be used with BusName=. Only after it successfully acquires the DBus space will dependent programs start.
• ExecStart: The command executed when the start command is issued. The program launched by this command must use an absolute path (e.g., you must use /sbin/arp instead of simply relying on environment variables to call arp).
• ExecStop: The command executed when the stop command is issued. The same requirement applies.
• ExecReload: This is optional. If not written, your service will not support the restart command. ExecStart and ExecStop are mandatory.

There are more parameters in the service body. Here are some commonly used ones:

• User: Specifies the user to run the service.
• Group: Specifies the user group to run the service.
• WorkingDirectory: The working directory of the process. The system will switch to this directory before execution.

Installing the Service [Install]

The installation section in the example above is:

[Install]
WantedBy=multi-user.target

• WantedBy: Sets who loads the service. It is generally set to multi-user.target.

Summary

Systemd Service is a better way to replace scripts under /etc/init.d/. It allows flexible control over when to start services and generally won't cause the system to fail to boot into emergency mode. If you want to set up something to start on boot, try writing a Systemd Service. Of course, the prerequisite is that your Linux distribution supports it.

This article references part of the content from: How to Write a Systemd Service