This chapter is from the book
This chapter is from the book
This chapter is from the book
Managing Systemd Targets
Systemd is the service in Red Hat Enterprise Linux 8 that is responsible for starting all kinds of things. Systemd goes way beyond starting services; other items are started from Systemd as well. In Chapter 11, “Working with Systemd,” you learned about the Systemd fundamentals; this chapter looks at how Systemd targets are used to boot your system into a specific state.
Understanding Systemd Targets
A Systemd target is basically just a group of units that belong together. Some targets are just that and nothing else, whereas other targets can be used to define the state a system is booting in, because these targets have one specific property that regular targets don’t have: they can be isolated. Isolatable targets contain everything a system needs to boot or change its current state. Four targets can be used while booting:
emergency.target: In this target only a minimal number of units are started, just enough to fix your system if something is seriously wrong. You’ll find that it is quite minimal, as some important units are not started.
rescue.target: This target starts all units that are required to get a fully operational Linux system. It doesn’t start nonessential services though.
multi-user.target: This target is often used as the default target a system starts in. It starts everything that is needed for full system functionality and is commonly used on servers.
graphical.target: This target also is commonly used. It starts all units that are needed for full functionality, as well as a graphical interface.
Working with Targets
Working with targets may seem complicated, but it is not. It drills down to three common tasks:
Adding units to be automatically started
Setting a default target
Running a nondefault target to enter troubleshooting mode
In Chapter 11 you learned how to use the systemctl enable and systemctl disable commands to add services to or remove services from targets. In this chapter you learn how to set a default target and how to run a nondefault target to enter troubleshooting mode. But first let’s take a closer look at the working of targets under the hood.
Understanding Target Units
Behind a target there is some configuration. This configuration consists of two parts:
The target unit file
The “wants” directory, which contains references to all unit files that need to be loaded when entering a specific target
Targets by themselves can have dependencies to other targets, which are defined in the target unit file. Example 17-1 shows the definition of the multi-user.target file, which defines the normal operational state of a RHEL server.
Example 17-1 The multi-user.target File
[root@localhost ~]# systemctl cat multi-user.target
# /usr/lib/systemd/system/multi-user.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
published by
# the Free Software Foundation; either version 2.1 of the License,
or
# (at your option) any later version.
[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
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 any information about the units that should be included; that is in the individual unit files and the wants (explained in the upcoming section “Understanding Wants”).
Systemd targets look a bit like runlevels used in previous versions of RHEL, but targets are more than that. A target is a group of units, and there are multiple different targets. Some targets, such as the multi-user.target and the graphical.target, define a specific state that the system needs to enter. Other targets just bundle a group of units together, such as the nfs.target and the printer.target. These targets are included from other targets, such as multi-user.target or graphical.target.
Understanding Wants
Understanding the concept of a want simply requires understanding the verb want in the English language, as in “I want a cookie.” Wants in Systemd define which units Systemd wants when starting a specific target. Wants are created when Systemd units are enabled using systemctl enable, and this happens by creating a symbolic link in the /etc/systemd/system directory. In this directory, you’ll find a subdirectory for every target, containing wants as symbolic links to specific services that are to be started.
Managing Systemd Targets
As an administrator, you need to make sure that the required services are started when your server boots. To do this, use the systemctl enable and systemctl disable commands. You do not have to think about the specific target a service has to be started in. Through the [Install] section in the service unit file, the services know for themselves in which targets they need to be started, and a want is created automatically in that target when the service is enabled. The following procedure walks you through the steps of enabling a service:
Type yum install -y vsftpd, followed by systemctl status vsftpd. If the service has not yet been enabled, the Loaded line will show that it currently is disabled:
[root@server202 ~]# systemctl status vsftpd vsftpd.service - Vsftpd ftp daemon Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled) Active: inactive (dead)Type ls /etc/systemd/system/multi-user.target.wants. You’ll see symbolic links that are taking care of starting the different services on your machine. You can also see that the vsftpd.service link does not exist.
Type systemctl enable vsftpd. The command shows you that it is creating a symbolic link for the file /usr/lib/systemd/system/vsftpd.service to the directory /etc/systemd/system/multi-user.target.wants. So basically, when you enable a Systemd unit file, in the background a symbolic link is created.
Isolating Targets
As already discussed, on Systemd machines there are several targets. You also know that a target is a collection of units. Some of those targets have a special role because they can be isolated. These are also the targets that you can set as the targets to get into after system start.
By isolating a target, you start that target with all of its dependencies. Only targets that have the isolate option enabled can be isolated. We’ll explore the systemctl isolate command later in this section. Before doing that, let’s take a look at the default targets on your computer.
To get a list of all targets currently loaded, type systemctl --type=target. You’ll see a list of all the targets currently active. If your server is running a graphical environment, this will include all the dependencies required to install the graphical.target also. However, this list shows only the active targets, not all the targets. Type systemctl --type=target --all for an overview of all targets that exist on your computer. You’ll now see inactive targets also (see Example 17-2).
Example 17-2 Showing System Targets
root@localhost ~]# systemctl --type=target --all
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
cryptsetup.target loaded active active Local Encrypted
Volumes
dbus.target not-found inactive dead dbus.target
emergency.target loaded inactive dead Emergency Mode
getty-pre.target loaded active active Login Prompts
(Pre)
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical
Interface
initrd-fs.target loaded inactive dead Initrd File
Systems
initrd-root-device.targetloaded inactive dead Initrd Root
Device
initrd-root-fs.target loaded inactive dead Initrd Root File
System
initrd-switch-root.targetloaded inactive dead Switch Root
initrd.target loaded inactive dead Initrd Default
Target
local-fs-pre.target loaded active active Local File
Systems (Pre)
local-fs.target loaded active active Local File
Systems
multi-user.target loaded active active Multi-User
System
network-online.target loaded active active Network is
Online
network-pre.target loaded active active Network (Pre)
network.target loaded active active Network
nfs-client.target loaded active active NFS client
services
nss-lookup.target loaded inactive dead Host and Network
Name Lookups
nss-user-lookup.target loaded active active User and Group
Name Lookups
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File
Systems (Pre)
remote-fs.target loaded active active Remote File
Systems
rescue.target loaded inactive dead Rescue Mode
rpc_pipefs.target loaded active active rpc_pipefs.
target
rpcbind.target loaded active active RPC Port Mapper
shutdown.target loaded inactive dead Shutdown
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
sshd-keygen.target loaded active active sshd-keygen.
target
swap.target loaded active active Swap
sysinit.target loaded active active System
Initialization
Of the targets on your system, a few have an important role because they can be started (isolated) to determine the state your server starts in. These are also the targets that can be set as the default targets. These targets also roughly correspond to runlevels used on earlier versions of RHEL. These are the following targets:
poweroff.target |
runlevel 0 |
rescue.target |
runlevel 1 |
multi-user.target |
runlevel 3 |
graphical.target |
runlevel 5 |
reboot.target |
runlevel 6 |
If you look at the contents of each of these targets, you’ll also see that they contain the AllowIsolate=yes line. That means that you can switch the current state of your computer to either one of these targets using the systemctl isolate command. Exercise 17-1 shows you how to do this.
Setting the Default Target
Setting the default target is an easy procedure that can be accomplished from the command line. Type systemctl get-default to see the current default target and use systemctl set-default to set the desired default target.
To set the graphical.target as the default target, you need to make sure that the required packages are installed. If this is not the case, you can use the yum group list command to show a list of all RPM package groups. The “server with gui” and “GNOME Desktop” package groups both apply. Use yum group install "server with gui" to install all GUI packages on a server where they have not been installed yet.