Chapter 11. Working with Systemd
The following topics are covered in this chapter:
The following RHCSA exam objective is covered in this chapter:
Start and stop services and configure services to start automatically at boot
In this chapter, you’ll learn about Systemd, which is the system and service manager used on RHEL 8. You’ll read about all the things that Systemd can do, and once you have a good general understanding, you’ll learn how to work with Systemd services. Systemd is also involved in booting your system in a desired state, which is called a target. That topic is covered in Chapter 17, “Managing and Understanding the Boot Procedure.”
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 11-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and ‘Review Questions.’”
Table 11-1 “Do I Know This Already?” Section-to-Question Mapping
Foundation Topics Section |
Questions |
|---|---|
1–5 |
|
6–10 |
1. Which command shows all service unit files on your system that are currently loaded?
a. systemctl --type=service
b. systemctl --type=service --all
c. systemctl --list-services
d. systemctl --show-units | grep services
2. Which statement about Systemd wants is not true?
a. You can create wants by using the systemctl enable command.
b. The target to which a specific want applies is agnostic of the associated wants.
c. Wants are always administered in the /usr/lib/systemd/system directory.
d. Each service knows to which target its wants should be added.
3. What is the best solution to avoid conflicts between incompatible units?
a. Nothing; the unit files have defined for themselves which units they are not compatible with.
b. Disable the service using systemctl disable.
c. Unmask the service using systemctl unmask.
d. Mask the service using systemctl mask.
4. Which of the following is not a valid status for Systemd services?
a. Running(active)
b. Running(exited)
c. Running(waiting)
d. Running(dead)
5. Which of the following statements is not true about socket units?
a. A socket unit requires a service unit with the same name.
b. Socket units can listen on ports and activate services only when activity occurs on a port.
c. Socket units cannot contain the name of the associated binary that should be started.
d. Socket units may react upon path activity.
6. Which of the following is not a valid Systemd unit type?
a. service
b. udev
c. mount
d. socket
7. You want to find out which other Systemd units have dependencies to a specific unit. Which command would you use?
a. systemd list-dependencies --reverse
b. systemctl list-dependencies --reverse
c. systemctl status my.unit --show-deps
d. systemd status my.unit --show-deps -r
8. How do you change the default editor that Systemd is using to vim?
a. export EDITOR=vim
b. export SYSTEMD_EDITOR=vim
c. export EDITOR=/bin/vim
d. export SYSTEMD_EDITOR=/bin/vim
9. Which of the following keywords should you use to define a Systemd dependency if you want to ensure that the boot procedure doesn’t fail if the dependency fails?
a. Required
b. Requisite
c. Before
d. Wants
10. Which of the following is not a valid command while working with units in systemctl?
a. systemctl unit start
b. systemctl status -l unit
c. systemctl mask unit
d. systemctl disable unit
Foundation Topics
Understanding Systemd
Systemd is the part of Red Hat Enterprise Linux 8 that is responsible for starting not only services but a variety of other items as well. In this chapter, you learn how Systemd is organized and what items are started from Systemd.
To describe it in a generic way, the Systemd System and Service Manager is used to start stuff. The stuff is referred to as units. Units can be many things. One of the most important unit types is the service. Typically, services are processes that provide specific functionality and allow connections from external clients coming in, such as the SSH service, the Apache web service, and many more. Apart from services, other unit types exist, such as socket, mount, and target. To display a list of available units, type systemctl -t help (see Example 11-1).
Example 11-1 Unit Types in Systemd
[root@server1 ~]# systemctl -t help Available unit types: service socket target device mount automount swap timer path slice scope
Understanding Systemd Unit Locations
The major benefit of working with Systemd, as compared to previous methods Red Hat used for managing services, is that it provides a uniform interface to start units. This interface is defined in the unit file. Unit files can occur in three locations:
/usr/lib/systemd/system contains default unit files that have been installed from RPM packages. You should never edit these files directly.
/etc/systemd/system contains custom unit files. It may also contain files that have been written by an administrator or generated by the systemctl edit command.
/run/systemd/system contains unit files that have automatically been generated.
If a unit file exists in more than one of these locations, units in the /run directory have highest precedence and will overwrite any settings that were defined elsewhere. Units in /etc/systemd/system have second highest precedence, and units in /usr/lib/systemd/system come last.
Understanding Systemd Service Units
Probably the most important unit type is the service unit. It is used to start processes. You can start any type of process by using a service unit, including daemon processes and commands.
Example 11-2 gives an example of a service unit file, vsftpd.service, for the Very Secure FTP service.
Example 11-2 Example of a Service Unit File
[Unit] Description=Vsftpd ftp daemon After=network.target [Service] Type=forking ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf [Install] WantedBy=multi-user.target
You can see from this unit file example that unit files are relatively easy to understand. Any Systemd service unit file consists of the following three sections (you’ll find different sections in other types of unit files):
[Unit] Describes the unit and defines dependencies. This section also contains the important After statement, and optionally the Before statement. These statements define dependencies between different units, and they relate to the perspective of this unit. The Before statement indicates that this unit should be started before the unit that is specified. The After statement indicates that this unit should be started after the unit that is specified.
[Service] Describes how to start and stop the service and request status installation. Normally, you can expect an ExecStart line, which indicates how to start the unit, or an ExecStop line, which indicates how to stop the unit. Note the Type option, which is used to specify how the process should start. The forking type is commonly used by daemon processes, but you can also use other types, such as oneshot, which will start any command from a Systemd unit. See man 5 systemd.service for more details.
[Install] Indicates in which target this unit has to be started. The section “Understanding Systemd Target Units” a bit later in this chapter explains how to work with targets.
Understanding Systemd Mount Units
A mount unit specifies how a file system can be mounted on a specific directory. Example 11-3 shows an example of a mount unit file, tmp.mount.
Example 11-3 Example of a Mount Unit File
[Unit] Description=Temporary Directory (/tmp) Documentation=man:hier(7) Documentation=https://www.freedesktop.org/wiki/Software/systemd/ APIFileSystems ConditionPathIsSymbolicLink=!/tmp DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target After=swap.target [Mount] What=tmpfs Where=/tmp Type=tmpfs Options=mode=1777,strictatime,nosuid,nodev
The tmp.mount unit file in Example 11-3 shows some interesting additional configuration options in its sections:
[Unit] The Conflicts statement is used to list units that cannot be used together with this unit. Use this for mutually exclusive units.
[Mount] Defines exactly where the mount has to be performed. You’ll recognize the arguments that are typically used in any mount command.
Understanding Systemd Socket Units
Another type of unit that is interesting to look at is the socket. A socket creates a method for applications to communicate with one another. A socket may be defined as a file, but also as a port on which Systemd will be listening for incoming connections. That way, a service doesn’t have to run continuously, but instead will start only if a connection is coming in on the socket that is specified. Every socket needs a corresponding service file. Example 11-4 shows what the cockpit.socket file looks like; notice that this file requires a service file with the name cockpit.service.
Example 11-4 Example of a Socket Unit File
[Unit] Description=Cockpit Web Service Socket Documentation=man:cockpit-ws(8) Wants=cockpit-motd.service [Socket] ListenStream=9090 ExecStartPost=-/usr/share/cockpit/motd/update-motd '' localhost ExecStartPost=-/bin/ln -snf active.motd /run/cockpit/motd ExecStopPost=-/bin/ln -snf /usr/share/cockpit/motd/inactive.motd /run/cockpit/motd [Install] WantedBy=sockets.target
The important option in Example 11-4 is ListenStream. This option defines the TCP port that Systemd should be listening to for incoming connections. Sockets can also be created for UDP ports, in which case you would use ListenDatagram instead of ListenStream.
Understanding Systemd Target Units
The unit files are used to build the functionality that is needed on your server. To make it possible to load them in the right order and at the right moment, a specific type of unit is used: the target unit. A simple definition of a target unit is “a group of units.” Some targets are used to define the state a server should be started in. As such, target units are comparable to the runlevels used in earlier versions of RHEL.
Other targets are just a group of services that makes it easy to manage not only individual units, but all the units that are required to get specific functionality. The printer.target is an example of such a target; you can use it to easily start or stop all units that are required to provide printing functionality.
Targets by themselves can have dependencies on other targets. These dependencies are defined in the target unit. An example of such a dependency relation is the basic.target. This target defines all the units that should always be started. You can use the systemctl list-dependencies command for an overview of any existing dependencies.
Example 11-5 shows the definition of a target unit file, multi-user.target, which defines the normal operational state of a RHEL server.
Example 11-5 Example of a Target Unit File
[Unit] Description=Multi-User System Documentation=man:systemd.special(7) Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target AllowIsolate=yes [Install] Alias=default.target
You can see that by itself the target unit does not contain much. It just defines what it requires and which services and targets it cannot coexist with. It also defines load ordering, by using the After statement in the [Unit] section. The target file does not contain information about the units that should be included; that is defined in the [Install] section of the different unit files.
When administrators use the systemctl enable command, to ensure that a unit is automatically started while booting, the [Install] section of that unit is considered to determine to which target the unit should be added.
When adding a unit to a target, under the hood a symbolic link is created in the target directory in /etc/systemd/system. If, for instance, you’ve enabled the vsftpd service to be automatically started, you’ll find that a symbolic link /etc/systemd/system/multi-user.target/wants/vsftpd.service has been added, pointing to the unit file in /usr/lib/systemd/system/vsftpd.service and thus ensuring that the unit will automatically be started. In Systemd terminology, this symbolic link is known as a want, because it defines what the target wants to start when it is processed.
Managing Units Through Systemd
Managing the current state of Systemd units it an important task of a RHEL administrator. Managing units means not only managing their current state, but also changing options used by the different units.
As an administrator, managing Systemd units starts with starting and stopping units. You use the systemctl command to do that. In Exercise 11-1, you start, stop, and manage a unit. After you have configured a unit so that it can be started without problems, you need to make sure that it restarts automatically upon reboot. You do this by enabling or disabling the unit.
Tip
The systemctl command has a large number of options, which may appear overwhelming at first sight, but there’s no need to be overwhelmed. Just ensure that the bash-completion package is installed and use Tab completion on the systemctl command, which provides easy access to all of the available options.
Exercise 11-1 Managing Units with systemctl
Type yum -y install vsftpd to install the Very Secure FTP service.
Type systemctl start vsftpd to activate the FTP server on your machine.
Type systemctl status vsftpd. You’ll get output as shown in Example 11-6, where you can see that the vsftpd service is currently operational. You can also see in the Loaded line that the service is currently disabled, which means that it will not be activated on a system restart. The vendor preset also shows as disabled, which means that by default after installation this unit will not automatically be enabled.
Type systemctl enable vsftpd. This creates a symbolic link in the wants directory for the multiuser target to ensure that the service is automatically started after a restart.
Type systemctl status vsftpd again. You’ll now see that the unit file has changed from being disabled to enabled.
Example 11-6 Requesting Current Unit Status with systemctl status
[root@server1 ~]# systemctl status vsftpd
vsftpd.service - Vsftpd ftp daemon
Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled;
vendor preset: disabled)
Active: active (running) since Mon 2019-06-10 06:44:18 EDT; 5s ago
Process: 10044 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
(code=exited, status=0/SUCCESS)
Main PID: 10045 (vsftpd)
Tasks: 1 (limit: 11365)
Memory: 696.0K
CGroup: /system.slice/vsftpd.service
10045 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
Jun 10 06:44:18 server1.example.com systemd[1]: Starting Vsftpd ftp
daemon...
Jun 10 06:44:18 server1.example.com systemd[1]: Started Vsftpd ftp
daemon.
When requesting the current status of a Systemd unit as in Example 11-6, you can see different kinds of information about it. Table 11-2 shows the different kinds of information that you can get about unit files when using the systemctl status command.
Table 11-2 Systemd Status Overview
Status |
Description |
|---|---|
Loaded |
The unit file has been processed and the unit is active. |
Active(running) |
The unit is running with one or more active processes. |
Active(exited) |
The unit has successfully completed a one-time run. |
Active(waiting) |
The unit is running and waiting for an event. |
Inactive(dead) |
The unit is not running. |
Enabled |
The unit will be started at boot time. |
Disabled |
The unit will not be started at boot time. |
Static |
The unit cannot be enabled but may be started by another unit automatically. |
As an administrator, you’ll also often need to get a current overview of the status of Systemd unit files. Different commands can help you to get this insight, some of which are shown in Table 11-3.
Table 11-3 systemctl Unit Overview Commands
Command |
Description |
|---|---|
systemctl --type=service |
Shows only service units |
systemctl list-units --type=service |
Shows all active service units (same result as the previous command) |
systemctl list-units --type=service --all |
Shows inactive service units as well as active service units |
systemctl --failed --type=service |
Shows all services that have failed |
systemctl status -l your.service |
Shows detailed status information about services |
Managing Dependencies
In general, there are two ways to manage Systemd dependencies:
Unit types such as socket and path are directly related to a service unit. Accessing either of these unit types will automatically trigger the service type.
Dependencies can be defined within the unit, using keywords like Requires, Requisite, After, and Before.
As an administrator, you can request a list of unit dependencies. Type systemctl list- dependencies followed by a unit name to find out which dependencies it has, and add the --reverse option to find out which units are dependents of this unit. Example 11-7 shows an example of this command.
Example 11-7 Showing Unit Dependencies
[root@server1 ~]# systemctl list-dependencies vsftpd vsftpd.service
To ensure accurate dependency management, different keywords can be used in the [Unit] section of a unit:
Requires: If this unit loads, units listed here will load also. If one of the other units is deactivated, this unit will also be deactivated.
Requisite: If the unit listed here is not already loaded, this unit will fail.
Wants: This unit wants to load the units that are listed here, but it will not fail if any of the listed unit fails.
Before: This unit will start before the unit specified with Before.
After: This unit will start after the unit specified with After.
In upcoming Exercise 11-2 you’ll learn how to use these options to manage unit dependency relations.
Managing Unit Options
When working with Systemd unit files, you risk getting overwhelmed with options. Every unit file can be configured with different options. To figure out which options are available for a specific unit, use the systemctl show command. For instance, the systemctl show sshd command shows all Systemd options that can be configured in the sshd.service unit, including their current default values. Example 11-8 shows the output of this command.
Example 11-8 Showing Available Options with systemctl show
[root@server1 ~]# systemctl show | head -20 Id=sshd.service Names=sshd.service Requires=basic.target Wants=sshd-keygen.service system.slice WantedBy=multi-user.target ConsistsOf=sshd-keygen.service Conflicts=shutdown.target ConflictedBy=sshd.socket Before=shutdown.target multi-user.target After=network.target sshd-keygen.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded ActiveState=active SubState=running FragmentPath=/usr/lib/systemd/system/sshd.service UnitFileState=enabled InactiveExitTimestamp=Sat 2015-05-02 11:06:02 EDT InactiveExitTimestampMonotonic=2596332166 ActiveEnterTimestamp=Sat 2015-05-02 11:06:02 EDT ActiveEnterTimestampMonotonic=2596332166 ActiveExitTimestamp=Sat 2015-05-02 11:05:22 EDT ActiveExitTimestampMonotonic=2559916100 InactiveEnterTimestamp=Sat 2015-05-02 11:06:02 EDT
When changing unit files to apply options, you need to make sure that the changes are written to /etc/systemd/system, which is the location where custom unit files should be created. The recommended way to do so is by using the systemctl edit command. This creates a subdirectory in /etc/systemd/system for the service that you are editing; for example, if you use systemctl edit sshd.service, you get a directory with the name /etc/systemd/systemd/sshd.service.d in which a file with the name override.conf is created. All settings that are applied in this file overwrite any existing settings in the service file in /usr/lib/systemd/system. In Exercise 11-2 you learn how to apply changes to Systemd units.
An alternative (but definitely not recommended) way of making changes to unit files is to copy the default unit file from /usr/lib/systemd/system to /etc/systemd/system, and make your settings in the unit file in this location. At least this approach ensures that your modifications won’t get lost after the default unit file gets updated.
Tip
By default, Systemd uses the nano editor. Not everybody likes that very much (including me). If you want vim to be used instead of nano, edit the /root/.profile file to include the following line: export SYSTEMD_EDITOR="/bin/vim". After logging in again, vim will be used as the default editor.
Exercise 11-2 Changing Unit Configuration
Type yum install httpd to install the Apache web server package.
Type systemctl cat httpd.service to show the current configuration of the unit file that starts the Apache web server.
Type systemctl show httpd.service to get an overview of available configuration options for this unit file.
Type systemctl edit httpd.service to change the default configuration, and ensure that the [Unit] section includes the lines Restart=always and RestartSec=5s.
Type systemctl daemon-reload to ensure that Systemd picks up the new configuration.
Type systemctl restart httpd to restart the httpd service.
Type systemctl status httpd and then repeat after 5 seconds. You’ll notice that the httpd process gets automatically restarted.
Summary
In this chapter you learned how to work with Systemd. You’ve read how to manage Systemd service state and how to change different options in Systemd. In the next chapter you’ll learn how to schedule tasks using the cron and at services.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have several choices for exam preparation: the end-of-chapter labs; the memory tables in Appendix B; Chapter 26, “Final Preparation”; and the practice exams.
Review All Key Topics
Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 11-4 lists a reference of these key topics and the page numbers on which each is found.
Table 11-4 Key Topics for Chapter 11
Key Topic Element |
Description |
Page Number |
|---|---|---|
Unit types in Systemd |
||
List |
Three sections of a Systemd unit file |
|
Section |
Understanding Systemd Target Units |
|
Managing units with systemctl |
||
systemctl unit overview commands |
Complete Tables and Lists from Memory
Print a copy of Appendix B, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix C, “Memory Tables Answer Key,” includes completed tables and lists to check your work.
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Review Questions
The questions that follow are meant to help you test your knowledge of concepts and terminology and the breadth of your knowledge. You can find the answers to these questions in Appendix A.
1. What is a unit?
2. Which command should you use to show all service units that are currently loaded?
3. How do you create a want for a service?
4. How do you change the default editor for systemctl?
5. Which directory contains custom Systemd unit files?
6. What should you include to ensure that a unit file will automatically load another unit file?
7. Which command will show available configuration options for the httpd.service unit?
8. Which command shows all dependencies for a specific unit?
9. What does it mean if systemctl status shows that a unit is dead?
10. How do you create a Systemd override file?
End-of-Chapter Lab
You have now learned how to work with Systemd. Before continuing, it is a good idea to work on a lab that helps you ensure that you can apply the skills that you acquired in this chapter.
Lab 11.1
1. Install the vsftpd and httpd services.
2. Set the default systemctl editor to vim.
3. Edit the httpd.service unit file such that starting httpd will always auto-start vsftpd. Edit the httpd service such that after failure it is automatically started again in 10 seconds.