In this guide will discuss how to manage and create systemd service. systemd is a system and service manager for Linux operating systems.
systemd provides features such as:
- On-demand activation of daemons
- Parallel start-up of system and services during boot
- Dependency based service control logic
- Start and enable services
systemd is the default systems manager for RPM-based operating systems from RHEL 7 upwards. Systemd uses a concept called systemd units.
systemd configuration files locations
These units are represented by configuration files located in different locations on Linux systems as described below:
| Directory | Description |
|---|---|
/usr/lib/systemd/system/ |
Systemd unit files that are distributed with installed RPM packages. |
/run/systemd/system/ |
Systemd unit files that are created at run time. This directory can overwrite the directory with installed service unit files. |
/etc/systemd/system/ |
Systemd unit files created by systemctl enable. It also contains the unit files that are manually created by a user. |
Different types of systemd units
There are different types of systemd units such as:
| Unit Type | File Extension | Description |
|---|---|---|
| Service unit | .service | A system service |
| Target unit | .target | A group of systemd units |
| Automount unit | .automount | A file system automount point |
| Device unit | .device | A device file recognized by the kernel |
| Mount unit | .mount | A file system mount point |
Manage services using systemd service unit
This guide shall cover how to use and manage services using the systemd service unit. By the end of this guide, we shall help you understand the following:
- What is a systemd service unit
- What are the sections in a systemd service unit
- What are the configuration options of the different sections of the service unit
- What are the commands to use to manage the systemd service unit
- How to create a systemd service unit file
A systemd service unit is a file with .service extension located in either of the described locations above which contains information about a process that is managed by systemd.
The Service Unit Sections
The service unit comprises three sections descried below:
- [Unit]: contains the options that are not dependent on the type of the unit. The options provide the unit description, set dependencies to other units, and specify the unit's behavior.
- [Service]: This contains information about the specific service type.
- [Install]: This contains information about the installation used by
systemctl enableanddisablecommands.
Below is a keen analysis of each of the three sections above.
The [Unit] Section
The [Unit] section of the .servicefile contains information about the description of the unit itself. This can be broken down into:
- Description - The description of the unit file. This is the text that will be displayed in the output of the
systemctl statuscommand. - Documentation - Provides a URL for the documentation of the unit
- After/Before - This defines the order in which the units will be started. This means that the unit can only start after/before another dependant unit is started.
- Requires - This configures dependencies on unit files. The units specified with this option are started simultaneously.
- Wants - Configures dependencies with less magnitude. This means that the unit can activate even when the specified units haven't started.
- Conflicts - Configures the opposite dependencies to those defined in the Requires section.
Note that these dependencies are not all required in a single unit. You could only make use of the description and the one more in case you need to start a simple service.
A sample Unit section will look like the one below:
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service
The [Service] Section
The [Service] section of the service unit is where the specific command such as the start, stop are configured. The [Service] section of the unit can be broken down into the following:
Service Type
This is the configuration that specifies the type of the unit process on startup. There are different types of services as stated below:
- simple – The default value. The process started with ExecStart is the main process of the service.
- forking – The process started with ExecStart spawns a child process that becomes the main process of the service. The parent process exits when the startup is complete.
- Oneshot – This type is similar to simple, but the process exits before starting consequent units.
- dbus – This type is similar to simple, but consequent units are started only after the main process gains a D-Bus name.
- notify – This type is similar to simple, but consequent units are started only after a notification message is sent via the sd_notify() function.
- idle – similar to simple, the actual execution of the service binary is delayed until all jobs are finished, which avoids mixing the status output with shell output of services.
ExecStart
The ExecStart option is used to specify the command that will be executed when the service starts. This can be a path to a binary file with other commands passed on or a path to a shell script. We can add commands to be executed before and after the initialization of the unit using the ExecStartPre and ExecStartPost options respectively. Type=oneshot enables specifying multiple custom commands that are then executed sequentially.
ExecStop
Specifies commands or scripts to be executed when the unit is stopped.
ExecReload
Specifies commands or scripts to be executed when the unit is reloaded.
Restart
With this option enabled, the service is restarted after its process exits, with the exception of a clean stop by the systemctl command.
RemainAfterExit
If set to True, the service is considered active even when all its processes exited. The default value is False. This option is especially useful if Type=oneshot is configured.
The example below show how a typical [Service] section looks like
[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/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop
The [Install] Section
The [Install] section is where we can specify options related to the service installation. Some of the attributes specified in this section are:
- Alias - Provides a space-separated list of additional names for the unit. Most systemctl commands, excluding systemctl enable, can use aliases instead of the actual unit name.
- RequiredBy - A list of units that depend on the unit. When this unit is enabled, the units listed in RequiredBy gain a Require dependency on the unit.
- WantedBy - A list of units that weakly depend on the unit. When this unit is enabled, the units listed in WantedBy gain a Want dependency on the unit.
- Also - Specifies a list of units to be installed or uninstalled along with the unit.
- DefaultInstance - Limited to instantiated units, this option specifies the default instance for which the unit is enabled.
[Install]
WantedBy=multi-user.target
Create systemd service unit file manually
As discussed before, to create systemd service unit file, we shall need to create a .service file under /etc/systemd/system/.
Let's say we want to create a service that will be used to manage Emacs text editor. We shall create a file called emacs.service at /etc/systemd/system/.
# touch /etc/systemd/system/emacs.service # chmod 664 /etc/systemd/system/emacs.service
We will add the following sections to our systemd service unit file:
[Unit] Description=Emacs: the extensible, self-documenting text editor [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
Make sure that you have Emacs installed installed.
[root@rockylinux-lab ~]# yum install emacs
Execute the command below to reload the system daemon and start the emacs service.
# systemctl daemon-reload # systemctl start emacs.service
Managing systemd services using systemctl (cheatsheet)
With the configuration done, let's look at how to manage these services using the systemctl utility.
The systemctl utility can be used to display, start, stop, restart a system service. This is further described below:
| systemctl | Description |
|---|---|
| systemctl start name.service | Starts a service. |
| systemctl stop name.service | Stops a service. |
| systemctl restart name.service | Restarts a service. |
| systemctl try-restart name.service | Restarts a service only if it is running. |
| systemctl reload name.service | Reloads configuration. |
| systemctl status name.service | Checks if a service is running. |
| systemctl is-active name.service | |
| systemctl list-units --type service --all | Displays the status of all services. |
| systemctl enable name.service | Enables a service. |
| systemctl disable name.service | Disables a service |
| systemctl status name.service | Checks if a service is running |
| systemctl is-enabled name.service | Checks if a service is enabled |
| systemctl list-unit-files --type service | Lists all services and checks if they are enabled. |
| systemctl list-dependencies --after | Lists services that are ordered to start before the specified unit. |
| systemctl list-dependencies --before | Lists services that are ordered to start after the specified unit. |
List available systemd services
For example, the output below shows what is expected when you run the command systemctl list-units --type service --all
[root@rockylinux-lab ~]# systemctl list-units --type service --all UNIT LOAD ACTIVE SUB DESCRIPTION auditd.service loaded active running Security Auditing Service cpupower.service loaded inactive dead Configure CPU power related settings crond.service loaded active running Command Scheduler dbus.service loaded active running D-Bus System Message Bus ● display-manager.service not-found inactive dead display-manager.service dm-event.service loaded inactive dead Device-mapper event daemon dnf-makecache.service loaded inactive dead dnf makecache dracut-cmdline.service loaded inactive dead dracut cmdline hook dracut-initqueue.service loaded inactive dead dracut initqueue hook dracut-mount.service loaded inactive dead dracut mount hook dracut-pre-mount.service loaded inactive dead dracut pre-mount hook dracut-pre-pivot.service loaded inactive dead dracut pre-pivot and cleanup hook dracut-pre-trigger.service loaded inactive dead dracut pre-trigger hook ...
Conclusion
In this guide, we have seen howto manage and create systemd service in Linux with examples. We have discussed the various sections of a systemd unit file, the various commands used to manage the systemd Unit file.
References
Managing and create systemd service in Linux
Managing SystemD services
