Home > Articles

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Foundation Topics

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’ll learn how to set a default target and how to run a nondefault target to enter troubleshooting mode. But first we’ll 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,
#  (at your option) any later version.

Description=Multi-User System
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.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 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:

  1. Type 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)
  2. 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.

  3. 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
  dbus.target              not-found inactive dead   dbus.target
  emergency.target         loaded    inactive dead   Emergency Mode
  getty-pre.target         loaded    active   active Login Prompts
  getty.target             loaded    active   active Login Prompts

graphical.target           loaded    active    active Graphical
 initrd-fs.target          loaded    inactive  dead   Initrd File
 initrd-root-device.target loaded    inactive  dead   Initrd Root
 initrd-root-fs.target     loaded    inactive  dead   Initrd Root File
 initrd-switch-root.target loaded    inactive  dead   Switch Root
 initrd.target             loaded    inactive  dead   Initrd Default
 local-fs-pre.target       loaded    active    active Local File
                                                        Systems (Pre)
 local-fs.target           loaded    active    active Local File
 multi-user.target         loaded    active    active Multi-User
 network-online.target     loaded    active    active Network is
 network-pre.target        loaded    active    active Network (Pre)
 network.target            loaded    active    active Network
 nfs-client.target         loaded    active    active NFS client
 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
 rescue.target             loaded    inactive  dead   Rescue Mode
 rpc_pipefs.target         loaded    active    active rpc_pipefs.
 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.
 swap.target               loaded    active    active Swap
 sysinit.target            loaded    active    active System

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.


Exercise 17-1 Isolating Targets

  1. From a root shell, go to the directory /usr/lib/systemd/system. Type grep Isolate *.target. This shows a list of all targets that allow isolation.

  2. Type systemctl isolate rescue.target. This switches your computer to rescue.target. You need to type the root password on the console of your server to log in.

  3. Type systemctl isolate reboot.target. This restarts your computer.

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.

  • + Share This
  • 🔖 Save To Your Account