Difference between revisions of "Configuring RHEL systemd Units"

Latest revision as of 16:06, 17 June 2019

In order to gain proficiency in RHEL 8 system administration it is important to understand the concepts of systemd units with a particular emphasis on two specific types known as services that run in the background of a running Linux system.

Understanding RHEL 8 systemd Targets

RHEL 8 can be configured to boot into one of a number of states (referred to as targets), each of which is designed to provide a specific level of operating system functionality. The target to which a system will boot by default is configured by the system administrator based on the purpose for which the system is being used. A desktop system, for example, will most likely be configured to boot using the graphical user interface target, while 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 previous RHEL versions, systemd targets are the replacement for the older runlevel system.

Understanding RHEL 8 systemd Services

A service is essentially 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 that is to be provided by that target.

Targets and services are types of systemd unit, a topic which will be covered later in this chapter.

RHEL 8 systemd Target Descriptions

As previously outlined, RHEL 8 can be booted into one of a number of 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:

• poweroff.target - This is the target in which the system shuts down. For obvious reasons 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. In this mode the system does not start any networking, graphical user interface or multi-user services. 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 also includes about 70 other targets, many of which are essentially sub-targets used by the above main targets. Behind the scenes, for example, multi-user.target will also start a target named sockets.target unit which is required for communication between different processes. This ensures that all of the services on which the multi-user target is dependent 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 111-1, for example, shows a partial listing of the systemd unit dependencies for the multi-user target (the full listing contains over 120 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 sub-dependencies 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 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:

• Green - The service or target is active and running.
• White - The service or target is inactive (dead). Typically because the service or target has not yet been 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 systemctl 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; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Thu 2019-02-14 15:27:47 EST; 1h 14min 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 8 system can be identified using the systemctl command as follows:

# systemctl get-default
multi-user.target

In the above case, the system is configured to boot using the multi-user target by default. The default setting can be changed at any time 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:

# systemctl set-default graphical.target
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 of the files within the /usr/lib/systemd/system folder are referred to as systemd unit configuration files, each of which represents a systemd unit. Each unit is, in turn, categorized as being of a particular unit type. RHEL 8 supports 12 different unit types including the target and service unit types already covered in this chapter.

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

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

Dynamically Changing the Current Target

The above step specifies the target that will be used the next time the system starts, but does not change the state of the currently running system. To change to a different target dynamically, use the systemctl command once again, this time 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 8 system will include the base systemd service units but is unlikely to include all of the services that will eventually be needed by the system once it goes into a production environment. A basic RHEL 8 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.

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 (in this case Red Hat) 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:

 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 next time the system reboots, the httpd service will not start automatically and will need to be started manually by the system administrator.

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)

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.

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. The multi-user.target unit, for example, 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 disable a service so that it no longer starts automatically as a target dependency, simply 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 which, 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:

# 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. In fact, as far has 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 so far in this chapter, it is also possible to review and manage systemd units from within the Cockpit web-based interface. Assuming that Cockpit has been installed and set up as outlined in the chapter entitled An Overview of the RHEL 8 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 111-4, for example, shows the detail screen for an httpd.service instance including service logs (A) and menu options (B) for performing tasks such as starting, stopping, enabling/disabling and masking/unmasking the unit.

Figure 11-4

Summary

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