Book Excerpt: A Practical Guide to Fedora and Red Hat Enterprise Linux

Displaying Properties

The following systemctl show command displays the Requires properties of the graphical.target unit. It shows that graphical.target requires multi-user.target:

$ systemctl show --property "Requires" graphical.target
Requires=multi-user.target

This relationship causes systemd not to start graphical.target if multi-user.target is not available. It means graphical.target requires units that multi-user.target requires and wants units that multi-user.target wants. Because of this relationship, multi-user.target (runlevel) is active at the same time graphical.target (runlevel) is active.

You can also use the systemctl show command to display the Wants properties of a target:

$ systemctl show --property "Wants" multi-user.target
Wants=systemd-update-utmp-runlevel.service NetworkManager.service ...
(END) q

The list is long. Although systemctl passes the output through a pager, it runs off the right edge of the screen. When the command displays (END), press q to return to the shell prompt. Sending the output through the fmt text formatter with a line-length specification of 10 displays the list one service per line:

$ systemctl show --property "Wants" multi-user.target | fmt -10
Wants=systemd-update-utmp-runlevel.service
NetworkManager.service
abrtd.service
ntpd.service
mcelog.service
rsyslog.service
...

To see if a target wants a specific service, send the output of the previous command through grep:

$ systemctl show --property "Wants" multi-user.target | fmt -10 | grep ntpd
ntpd.service
ntpdate.service

The output shows that multi-user.target wants the ntpd.service service. Because graphical.target requires multi-user.target and multi-user.target wants ntpd.service, systemd will start ntpd.service when the system enters the runlevel defined by graphical.target.

/etc/systemd/system Hierarchy: Controls Services and the Persistent Runlevel

The services wanted by a runlevel target appear in directories named .wants under the /etc/systemd/system directory:

$ ls -ld /etc/systemd/system/.wants
...
drwxr-xr-x. 2 root root 4096 04-20 17:10 /etc/systemd/system/graphical.target.wants
drwxr-xr-x. 2 root root 4096 04-20 17:10 /etc/systemd/system/multi-user.target.wants
...

The following command lists the runlevel targets that want ntpd.service:

$ ls /etc/systemd/system/.wants/ntpd.service
/etc/systemd/system/multi-user.target.wants/ntpd.service

As explained in the previous section, you can also display this information using the systemctl show command.

The directory hierarchy with its root at /etc/systemd/system controls the persistent runlevel of the system. That is, this directory hierarchy specifies which daemons will be started when the system boots or otherwise changes runlevel or when the daemon is activated for another reason.

All service unit files are kept in the /lib/systemd/system directory. All plain files in the /etc/systemd/system hierarchy are links to files in the /lib/systemd/system hierarchy. For example, ntpd.service shown in the preceding example is a link to the appropriate service unit file in /lib/systemd/system:

$ ls -l /etc/systemd/system/multi-user.target.wants/ntpd.service
lrwxrwxrwx. 1 root root 32 04-08 14:34 /etc/systemd/system/multi-user.target.wants/ntpd.service -> 
/lib/systemd/system/ntpd.service

The service unit file provides systemd with information it needs to start the service and specifies the system runlevel target that wants the service:

$ cat /lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=syslog.target ntpdate.service

[Service]
EnvironmentFile=/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd -n -u ntp:ntp $OPTIONS

[Install]
WantedBy=multi-user.target

When you instruct systemd to start a service when the system boots (make the service persistent), it places a link to the service file in the directory specified by _WantedBy in the service file. Continuing with the example, systemd places a link to ntpd.service in the multi-user.target.wants directory as shown previously. When you instruct systemd to not start a service when the system boots, it removes the link. “Setting the Persistent State of a Daemon (Service)” explains how to use systemctl to make these changes.

The persistent (default) runlevel is also controlled by a link:

$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 04-20 10:07 /etc/systemd/system/default.target -> 
/lib/systemd/system/runlevel5.target

See “Setting the Persistent Runlevel” for more information.

Custom Service Files

As explained in the previous section, files in the /etc/systemd/system directory hierarchy are symbolic links to files in the /lib/systemd/system directory hierarchy. The systemd init daemon treats files in the /etc/systemd/system directory hierarchy and files in the /lib/systemd/system directory hierarchy the same way, with files in /etc/systemd/system overriding files with the same name in /lib/systemd/system. An important difference between these directory hierarchies is that /lib/systemd/system is managed by yum/RPM while /etc/systemd/system is managed by the system administrator.

Put custom service files in the /etc/systemd/system hierarchy. If you want to modify a service file, copy it from the /lib/systemd/system hierarchy to the /etc/systemd/system hierarchy and edit the copy. The custom file in the /etc/systemd/system hierarchy will not be overwritten by yum/RPM and will take precedence over a file with the same name in the /lib/systemd/system hierarchy.

Determining if systemd runs a Daemon Natively

To ease migration from a SysVinit and Upstart to systemd and to provide compatibility with software intended for other distributions, systemd can control daemons via SysVinit scripts. You can use the systemctl status command to determine if systemd is controlling a daemon natively or via a SysVinit script. Following, systemctl displays the status of dhcpd and sshd:

$ systemctl status dhcpd.service
dhcpd.service - DHCPv4 Server Daemon
          Loaded: loaded (/lib/systemd/system/dhcpd.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/dhcpd.service
$ systemctl status sshd.service
sshd.service - LSB: Start up the OpenSSH server daemon
          Loaded: loaded (/etc/rc.d/init.d/sshd)
          Active: active (running) since Wed, 20 Apr 2011 19:08:32 -0700; 19h ago
        Main PID: 817 (sshd)
          CGroup: name=systemd:/system/sshd.service
                  + 817 /usr/sbin/sshd

The systemctl utility requires a period and unit type (.service in the preceding example) following a unit name (dhcpd and sshd in the preceding example). The lines that start with Loaded name the file controlling each daemon (service). The dhcpd daemon is controlled by /lib/systemd/system/dhcpd.service. The location of the file (the /lib/systemd hierarchy) and its filename extension (.service) indicate systemd is running the daemon natively. The sshd daemon is controlled by /etc/rc.d/init.d/sshd. The location of the file (the init.d directory) and the lack of a filename extension indicate systemd is running the daemon via a SysVinit script. See fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability for a list of services that have been ported to systemd (and are run natively by systemd).

You can use service to display the same information as systemctl status. However, service does not accept a period and unit type.

# service dhcpd status
dhcpd.service - DHCPv4 Server Daemon
          Loaded: loaded (/lib/systemd/system/dhcpd.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/dhcpd.service
# service sshd status
sshd.service - LSB: Start up the OpenSSH server daemon
          Loaded: loaded (/etc/rc.d/init.d/sshd)
          Active: active (running) since Wed, 20 Apr 2011 19:08:32 -0700; 19h ago
        Main PID: 817 (sshd)
          CGroup: name=systemd:/system/sshd.service
                  + 817 /usr/sbin/sshd

Setting and Changing Runlevels

The runlevel specifies which daemons are running and which interfaces are available on a system. See “Runlevels” and Table 11-1 for more information. This section describes how to set the persistent (default) runlevel (the runlevel the system boots to) and how to change the current runlevel.

Setting the Persistent Runlevel

Under systemd no true runlevels exist; see “Runlevels” For example, the default runlevel under Fedora is graphical.target and has an alternative name of runlevel5.target. Under SysVinit this runlevel is referred to as runlevel 5 (multiuser graphical mode). The /etc/systemd/system/default.target file is a link to the file that specifies the target the system will boot to by default:

$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 36 04-20 10:07 /etc/systemd/system/default.target -> /lib/systemd/system/runlevel5.target

The following command shows runlevel5.target is a link to graphical.target:

$ ls -l /lib/systemd/system/runlevel5.target
lrwxrwxrwx. 1 root root 16 04-08 14:33 /lib/systemd/system/runlevel5.target -> graphical.target

The multi-user.target file (and the link to it, runlevel3.target) causes the system to boot to the multiuser runlevel (multiuser textual mode; SysVinit runlevel 3). The following command replaces the link shown in the previous example and will cause the system enter multiuser textual mode each time it is booted. This command does not change the current runlevel.

# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

The –s (symbolic) option creates a symbolic link, and the –f (force) option overwrites any existing file. After giving the preceding command and rebooting the system, the systemctl list-units command shows the system is in multiuser mode:

$ systemctl list-units --type=target
...
multi-user.target         loaded active active     Multi-User
...