Managing RHEL 9 systemd Units

To gain proficiency in RHEL 9 system administration, it is essential to understand the concepts of systemd units with a particular emphasis on two specific types known as targets and services. This chapter aims to provide a basic overview of the different systemd units supported by RHEL 9 combined with an overview of how to configure the many services that run in the background of a running Linux system.

Understanding RHEL 9 systemd Targets

RHEL 9 can be configured to boot into one of several states (referred to as targets), each designed to provide a specific level of operating system functionality. The system administrator configures the target to which a system will boot by default based on the purpose for which the system is being used. A desktop system, for example, will likely be configured to boot using the graphical user interface target. In contrast, a cloud-based server system would be more likely to boot to the multi-user target level.

During the boot sequence, a process named systemd looks in the /etc/systemd/system folder to find the default target setting. Having identified the default target, it proceeds to start the systemd units associated with that target so that the system boots with all the necessary processes running. For those familiar with older RHEL versions, systemd targets replace the older runlevel system.

Understanding RHEL 9 systemd Services

A service is a process, typically running in the background, that provides specific functionality. The sshd service, for example, is the background process (also referred to as a daemon) that provides secure shell access to the system. Different systemd targets are configured to automatically launch different collections of services, depending on the functionality to be provided by that target. Targets and services are types of systemd unit, a topic that will be covered later in this chapter.

RHEL 9 systemd Target Descriptions

As previously outlined, RHEL 9 can be booted into one of several target levels. The default target to which the system is configured to boot will, in turn, dictate which systemd units are started. The targets that relate specifically to system startup and shutdown can be summarized as follows:

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

  • poweroff.target – This is the target in which the system shuts down. Obviously, it is unlikely you would want this as your default target.
  • rescue.target – Causes the system to start up in a single-user mode under which only the root user can log in. The system does not start any networking, graphical user interface, or multiuser services in this mode. This run level is ideal for system administrators to perform system maintenance or repair activities.
  • multi-user.target – Boots the system into a multi-user mode with text-based console login capability.
  • graphical.target – Boots the system into a networked, multi-user state with X Window System capability. By default, the graphical desktop environment will start at the end of the boot process. This is the most common run level for desktop or workstation use.
  • reboot.target – Reboots the system. Another target that, for obvious reasons, you are unlikely to want as your default.

In addition to the above targets, the system includes about 70 other targets, many of which are sub-targets used by the above main targets. Behind the scenes, for example, multi-user.target will also start a target named basic.target which will, in turn, start the sockets.target unit, which is required for communication between different processes. This ensures that all the services on which the multi-user target depends are also started during the boot process.

A list of the targets and services on which a specified target is dependent can be viewed by running the following command in a terminal window:

# systemctl list-dependencies <target>

Figure 11-1, for example, shows a partial listing of the systemd unit dependencies for the multiuser target (the complete listing contains over 140 targets and services required for a fully functional multi-user system):

Figure 11-1

The listing is presented as a hierarchical tree illustrating how some dependencies have subdependencies of their own. Scrolling to the bottom of the list, for example, would reveal that the multi-user target depends on two network filesystem related targets (namely nfs-client.target and remote-fs.target), each with its own service and target sub-dependencies:

Figure 11-2

The colored dots to the left of each entry in the list indicate the current status of that service or target as follows:

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

  • Green – The service or target is active and running.
  • White – The service or target is inactive (dead). Typically because the service or target has yet to be enabled, has been stopped for some reason, or a condition on which the service or target depends has not been met.
  • Red – The service or target failed to start due to a fatal error.

To find out more details about the status of a systemd unit, use the systemctl status command followed by the unit name as follows:

# systemctl status systemd-machine-id-commit.service
○ systemd-machine-id-commit.service - Commit a transient machine-id on disk
     Loaded: loaded (/usr/lib/systemd/system/systemd-machine-id-commit.service; static)
     Active: inactive (dead)
  Condition: start condition failed at Thu 2023-03-30 08:41:05 EDT; 16min ago
             └─ ConditionPathIsMountPoint=/etc/machine-id was not met
       Docs: man:systemd-machine-id-commit.service(8)

Identifying and Configuring the Default Target

The current default target for a RHEL 9 system can be identified using the systemctl command as follows:

# systemctl get-default
multi-user.target

The system is configured to boot using the multi-user target by default in the above case. The default setting can be changed anytime using the systemctl command with the set-default option. The following example changes the default target to start the graphical user interface the next time the system boots:

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.

The output from the default change operation reveals the steps performed in the background by the systemctl command to implement the change. The current default is configured by establishing a symbolic link from the default.target file located in /etc/systemd/system to point to the corresponding target file located in the /usr/lib/systemd/system folder (in this case the graphical.target file).

Understanding systemd Units and Unit Types

As previously mentioned, targets and services are both types of systemd unit. All the files within the /usr/lib/systemd/system folder are referred to as systemd unit configuration files, each representing a systemd unit. Each unit is, in turn, categorized as being of a particular unit type. RHEL 9 supports 12 different unit types, including the target and service unit types already covered in this chapter.

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

The type of a unit file is represented by the filename extension as outlined in below:

Unit Type

Filename Extension

Type Description

Service

.service

System service.

Target

.target

Group of systemd units.

Automount

.automount

File system auto-mount point.

Device

.device

Device file recognized by the kernel.

Mount

.mount

File system mount point.

Path

.path

File or directory in a file system.

Scope

.scope

Externally created process.

Slice

.slice

Group of hierarchically organized units that manage system processes.

Snapshot

.snapshot

Saved state of the systemd manager.

Socket

.socket

Inter-process communication socket.

Swap

.swap

Swap device or a swap file.

Timer

.timer

Systemd timer.

Table 11-1

Note that the target unit type differs from other types in that it comprises a group of systemd units such as services or other targets.

Dynamically Changing the Current Target

The systemctl set-default command outlined previously specifies the target that will be used the next time the system starts but does not change the current system’s state. To change to a different target dynamically, use the systemctl command again, using the isolate option followed by the destination target. To switch the current system to the graphical target without rebooting, for example, the following command would be used:

# systemctl isolate graphical.target

Once executed, the system will start the graphical desktop environment.

Enabling, Disabling, and Masking systemd Units

A newly installed RHEL 9 system will include the base systemd service units but is unlikely to include all the services the system will eventually need once it goes into a production environment. A basic RHEL 9 installation, for example, will typically not include the packages necessary to run an Apache web server, a key element of which is the httpd.service unit.

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

The system administrator will resolve this problem by installing the necessary httpd packages using the following command:

# dnf install httpd

Having configured the web server, the next task will be to check the status of the httpd service unit to identify whether it was activated as part of the installation process:

# systemctl status httpd.service
 httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:httpd.service(8)

Note that the service has loaded but is inactive because it is preset by the vendor to be disabled when first installed. To start the service, the following command can be used:

# systemctl start httpd.service

A status check will now indicate that the service is active:

# systemctl status httpd.service
 httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-02-15 11:13:26 EST; 8s ago
     Docs: man:httpd.service(8)
 Main PID: 10721 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 13923)
   Memory: 24.1M
.
.
.

Note, however, that the status indicates that the service is still disabled. This means that the next time the system reboots, the httpd service will not start automatically and will need to be started manually by the system administrator.

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

To configure the httpd service to start automatically each time the system starts, it must be enabled as follows:

# systemctl enable httpd.service

Once the service has been enabled, the Loaded section of the status output will read as follows:

Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
# systemctl status httpd.service
● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2023-03-30 09:04:21 EDT; 2min 17s ago
       Docs: man:httpd.service(8)
   Main PID: 4500 (httpd)
     Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec:   0 B/sec"
      Tasks: 213 (limit: 22087)
     Memory: 35.4M
.
.

As we can see from the above output, the httpd service is already loaded and active without being manually started. This is because the vendor preset is set to enable to ensure the service starts after installation is complete.

A currently running service may be stopped at any time as follows:

# systemctl stop httpd.service

Now that it has been enabled, the next time the system reboots to the current target, the httpd service will start automatically. Assuming, for example, that the service was enabled while the system was running the multi-user target, the httpd service will have been added as another dependency to the multi-user.target systemd unit.

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

Behind the scenes, systemctl adds dependencies to targets by creating symbolic links in the .wants folder for the target within the /etc/systemd/system folder. For example, the multi-user.target unit has a folder named multi-user.target.wants in /etc/systemd/system containing symbolic links to all of the systemd units located in /usr/lib/systemd/system on which it is dependent. A review of this folder will show a correlation with the dependencies listed by the systemctl list-dependencies command outlined earlier in the chapter.

To configure a service so that it no longer starts automatically as a target dependency, disable it as follows:

# systemctl disable httpd.service

This command will remove the symbolic link to the httpd.service unit file from the .wants directory so that it is no longer a dependency and, as such, will not be started the next time the system boots.

The .wants folder contains dependencies that, if not available, will not prevent the unit from starting and functioning. Mandatory dependencies (in other words, dependencies that will cause the unit to fail if not available) should be placed in the .requires folder (for example, multi-user. target.requires).

In addition to enabling and disabling, it is also possible to mask a systemd unit as follows:

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 

# systemctl mask httpd.service

A masked systemd unit cannot be enabled, disabled, or started under any circumstances, even if it is listed as a dependency for another unit. As far as the system is concerned, it is as though a masked systemd unit no longer exists. This can be useful for ensuring that a unit is never started, regardless of the system conditions. The only way to regain access to the service is to unmask it:

# systemctl unmask httpd.service

Working with systemd Units in Cockpit

In addition to the command-line techniques outlined in this chapter, it is also possible to review and manage systemd units from within the Cockpit web-based interface. For example, assuming that Cockpit has been installed and set up as outlined in the chapter entitled An Overview of the RHEL 9 Cockpit Web Interface, access to the list of systemd units on the system can be accessed by logging into Cockpit and selecting the Services option in the left-hand navigation panel marked A in Figure 11-3:

Figure 11-3

The button marked B displays units of specific types in the main area marked C where the current status of each unit is listed in the State column.

Selecting a unit from the list will display detailed information. Figure 11-4, for example, shows the detail screen for an httpd instance, including service logs (A) and a switch and menu (B) for performing tasks such as starting, stopping, enabling/disabling, and masking/unmasking the unit:

Figure 11-4

Summary

A newly installed RHEL 9 system includes a base set of systemd units, many of which run in the background to provide much of the system’s functionality. These units are categorized by type, the most common being targets and services. A target unit is a group of other units to be started collectively. The system has a default target unit that defines the other units to be started up each time the system boots. The most common targets are those which boot the system to either multiuser or graphical mode. In addition, the systemctl command-line tool provides a range of options for performing systemd unit configuration tasks, many of which are also available through the Cockpit web-based interface.

 

You are reading a sample chapter from Red Hat Enterprise Linux 9 Essentials. Buy the full book now in eBook or Print format.

Includes 34 chapters and 290 pages. Learn more.

Preview  Buy eBook Buy Print

 


Categories