Exploring Unit Files

The easiest way to start exploring systemd is through the systemd units. A unit defines a service, a group of services, or an action. Each unit consists of a name, a type, and a configuration file. There are currently 12 different systemd unit types, as follows:

• automount
• device
• mount
• path
• scope
• service
• slice
• snapshot
• socket
• swap
• target
• timer

The systemctl utility is the main gateway to managing systemd and system services. Its basic syntax is as follows:

systemctl [OPTIONS...] COMMAND [NAME...]

You can use the systemctl utility to provide a list of the various units currently loaded in your Linux system. A snipped example is shown in Listing 6.4.

Listing 6.4: Looking at systemd units

$ systemctl list-units
UNIT                       LOAD   ACTIVE SUB       DESCRIPTION
[...]
smartd.service             loaded active running   Self Monitor[...]
sshd.service               loaded active running   OpenSSH serv[...]
sysstat.service            loaded active exited    Resets Syste[...]
[...]
graphical.target            loaded active active    Graphical I[...]
[...]
$

In Listing 6.4 you can see various units as well as additional information. Units are identified by their name and type using the format name.type. System services (daemons) have unit files with the .service extension. Thus, the secure shell (ssh) daemon, sshd, has a unit file name of sshd.service.

Groups of services are started via target unit files. At system startup, the default.target unit is responsible for ensuring that all required and desired services are launched at system initialization. It is set up as a symbolic link to another target unit file, as shown in Listing 6.5 on a CentOS distribution.

Listing 6.5: Looking at the default.target link

$ find / -name default.target 2>/dev/null
/etc/systemd/system/default.target
[...]
$
$ readlink -f /etc/systemd/system/default.target
/usr/lib/systemd/system/graphical.target
$
$ systemctl get-default
graphical.target
$

First, in Listing 6.5, the default.target unit’s full file name is located via the find utility. The readlink command is then employed to find the actual target file, which determines what services to start at system boot. In this case, the target unit file is graphical.target.

Also notice in Listing 6.5 that the systemctl command is much easier to use than the other two commands. It is simply systemctl get-default, and it displays the actual target file. Due to the default.target file being located in different directories on the different distros, it is always best to use the systemctl utility. Table 6.1 shows the more commonly used system boot target unit files.

In Table 6.1, you’ll notice that systemd provides backward compatibility to the classic SysV init systems. The SysV runlevels will be covered later in this chapter.

Focusing on Service Unit Files

Service unit files contain information, such as which environment file to use, when a service must be started, what targets want this service started, and so on. These configuration files are located in different directories.

Keep in mind that a unit configuration file’s directory location is critical, because if a file is found in two different directory locations, one will have precedence over the other. The following list shows the directory locations in ascending priority order:

1. /etc/systemd/system/
2. /run/systemd/system/
3. /usr/lib/systemd/system/

To see the various service unit files available, you can again employ the systemctl utility. However, a slightly different command is needed than when viewing units, as shown in Listing 6.6.

Listing 6.6: Looking at systemd unit files

$ systemctl list-unit-files
UNIT FILE                                     STATE
[...]
dev-hugepages.mount                           static
dev-mqueue.mount                              static
proc-fs-nfsd.mount                            static
[...]
nfs.service                                   disabled
nfslock.service                               static
ntpd.service                                  disabled
ntpdate.service                               disabled
[...]
ctrl-alt-del.target                           disabled
default.target                                static
emergency.target                              static
[...]
$

Besides the unit file’s base name, you can also see a unit file’s state in Listing 6.6. Their states are called enablement states and refer to when the service is started. There are at least 12 different enablement states, but you’ll commonly see these three:

• enabled: Service starts at system boot.
• disabled: Service does not start at system boot.
• static: Service starts if another unit depends on it. Can also be manually started.

To see what directory or directories store a particular systemd unit file(s), use the systemctl utility. An example on a CentOS distribution is shown in Listing 6.7.

Listing 6.7: Finding and displaying a systemd unit file

$ systemctl cat ntpd.service
# /usr/lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=syslog.target ntpdate.service sntp.service
[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS
PrivateTmp=true
[Install]
WantedBy=multi-user.target
$

Notice in Listing 6.7 that the first displayed line shows the ntpd.service unit file’s base name and directory location. The next several lines are the unit configuration file’s contents.

For service unit files, there are three primary configuration sections. They are as follows:

• [Unit]
• [Service]
• [Install]

Within the service unit configuration file’s [Unit] section, there are basic directives. A directive is a setting that modifies a configuration, such as the After setting shown in Listing 6.7. The more commonly used [Unit] section directives are described in Table 6.2

The [Service] directives within a unit file set configuration items, which are specific to that service. The more commonly used [Service] section directives are described in Table 6.3.

The [Service] Type directive needs a little more explanation than what is given in Table 6.3. This directive can be set to at least six different specifications, of which the most typical are listed here:

• forking: ExecStart starts a parent process. The parent process creates the service’s main process as a child process and exits.
• simple: (Default) ExecStart starts the service’s main process.
• oneshot: ExecStart starts the service’s main process, which is typically a configuration setting or a quick command, and the process exits.
• idle: ExecStart starts the service’s main process, but it waits until all other start jobs are finished.

Another [Service] configuration setting that needs additional explanation is the Environment directive. Linux systems use a feature called environment variables to store information about the shell session and working environment (thus the name environment variable). If you want to ensure that a particular environment variable is set properly for your service, you will want to employ the Environment directive. A snipped example on a CentOS distribution is shown in Listing 6.8.

Listing 6.8: Viewing a service unit file’s Environment directive

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:[...]
$
$ systemctl ––no-pager cat anaconda.service
# /usr/lib/systemd/system/anaconda.service
[Unit]
Description=Anaconda
[...]
[Service]
Type=forking
Environment=HOME=/root MALLOC_CHECK_=2 MALLOC_PERTURB_=204 PATH=/usr/bin: /bin:/sbin:/usr/sbin:/mnt/sysimage/bin: [...]
LANG=en_US.UTF-8 [...]
[...]
$

In Listing 6.8, you can see that the PATH environment variable’s contents are displayed. This environment variable is a colon-separated list of directories where the process looks for commands. The anaconda.service unit file uses the Environment directive to set particular environment variables to its own desired environment parameters. These parameters are separated by a space. You can see in Listing 6.8 that one of those parameters set by the Environment directive is PATH.

The [Install] directives within a unit file determine what happens to a particular service if it is enabled or disabled. An enabled service is one that starts at system boot. A disabled service is one that does not start at system boot. The more commonly used [Install] section directives are described in Table 6.4.

Focusing on Target Unit Files

For systemd, you need to understand the service unit files as well as the target unit files. The primary purpose of target unit files is to group together various services to start at system boot time. The default target unit file, default.target, is symbolically linked to the target unit file used at system boot. In Listing 6.9, the default target unit file is located and displayed using the systemctl command.

Listing 6.9: Finding and displaying the systemd target unit file

$ systemctl get-default
graphical.target
$
$ systemctl cat graphical.target
# /usr/lib/systemd/system/graphical.target
[...]
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
$

Notice in the Listing 6.9 that the graphical.target unit file has many of the same directives as a service unit file. These directives were described back in Table 6.2. Of course, these directives apply to a target type unit file instead of a service type unit file. For example, the After directive in the graphical.target unit file sets this target unit to start after the designated units, such as multi-user.target. Target units, similar to service units, have various target dependency chains as well as conflicts.

In Listing 6.9, there is one directive we have not covered yet. The AllowIsolate directive, if set to yes, permits this target file to be used with the systemctl isolate command. This command is covered later in this chapter.

Looking at systemctl

You may have noticed that while there are various commands to manage systemd and system services, it is easier and faster to employ the systemctl utility.

There are several basic systemctl commands available for you to manage system services. One that is often used is the status command. It provides a wealth of information. A couple of snipped examples on a CentOS distro are shown in Listing 6.10.

Listing 6.10: Viewing a service unit’s status via systemctl

$ systemctl status ntpd
• ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service;
 disabled; vendor preset: disabled)
   Active: inactive (dead)
$ systemctl status sshd
• sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service;
 enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-09-07 15:5[...]
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1130 (sshd)
    Tasks: 1
   CGroup: /system.slice/sshd.service
           └─1130 /usr/sbin/sshd -D
$

In Listing 6.10, the first systemctl command shows the status of the ntpd service. Notice the third line in the utility’s output. It states that the service is disabled. The fourth line states that the service is inactive. In essence, this means that the ntpd service is not running (inactive) and is not configured to start at system boot time (disabled). Another item to look at within the ntpd service’s status is the Loaded line. Notice that the unit file’s complete file name and directory location is shown.

The status of the sshd service is also displayed, showing that sshd is running (active) and configured to start at system boot time (enabled).

There are several simple commands you can use with the systemctl utility to manage systemd services and view information regarding them. The more common commands are listed in Table 6.5. These systemctl commands generally use the following syntax:

systemctl COMMAND UNIT-NAME...

Notice the difference in Table 6.5 between the daemon-reload and reload command. This is an important difference. Use the daemon-reload command if you need to load systemd unit file configuration changes for a running service. Use the reload command to load a service’s modified configuration file. For example, if you modified the ntpd service’s configuration file, /etc/ntp.conf, and wanted the new configuration to take immediate effect, you would issue the command systemctl reload ntpd at the command line.

Besides the commands in Table 6.5, there are some other handy systemctl commands you can use for managing system services. An example on a CentOS distro is shown in Listing 6.11.

Listing 6.11: Determining if a service is running via systemctl

# systemctl stop sshd
#
# systemctl is-active sshd
inactive
#
# systemctl start sshd
#
# systemctl is-active sshd
active
#

In Listing 6.11, the OpenSSH daemon (sshd) is stopped using systemctl and its stop command. Instead of the status command, the is-active command is used to quickly display that the service is stopped (inactive). The OpenSSH service is started back up and again the is-active command is employed showing that the service is now running (active). Table 6.6 shows these useful service status checking commands.

Services can fail for many reasons: for hardware issues, a missing dependency set in the unit configuration file, an incorrect permission setting, and so on. You can employ the systemctl utility’s is-failed command to see if a particular service has failed. An example is shown in Listing 6.12.

Listing 6.12: Determining if a service has failed via systemctl

$ systemctl is-failed NetworkManager-wait-online.service
failed
$
$ systemctl is-active NetworkManager-wait-online.service
failed
$

In Listing 6.12, you can see that this particular service has failed. Actually, it was a failure forced by disconnecting the network cable prior to boot, so you could see a service’s failed status. If the service was not in failed state, the is-failed command would show an active status.

Examining Special systemd Commands

The systemctl utility has several commands that go beyond service management. Also, systemd has some special commands. You can manage what targets (groups of services) are started at system boot time, jump between various system states, and even analyze your system’s boot time performance. We’ll look at these various commands in this section.

One special command to explore is the systemctl is-system-running command. An example of this command is shown in Listing 6.13.

Listing 6.13: Determining a system’s operational status

$ systemctl is-system-running
running
$

You may think the status returned here is obvious, but it means all is well with your Linux system currently. Table 6.7 shows other useful statuses.

The maintenance operational status will be covered shortly in this chapter. If you receive degraded status, however, you should review your units to see which ones have failed and take appropriate action. Use the systemctl ––failed command to find the failed unit(s), as shown snipped in Listing 6.14.

Listing 6.14: Finding failed units

$ systemctl is-system-running
degraded
$
$ systemctl ––failed
  UNIT         LOAD   ACTIVE SUB    DESCRIPTION
• rngd.service loaded failed failed Hardware RNG Entropy Gatherer Daemon
[...]
$

Other useful systemctl utility commands deal with obtaining, setting, and jumping the system’s target. They are as follows:

• get-default
• set-default
• isolate

You’ve already seen the systemctl get-default command in action within Listing 6.5. This command displays the system’s default target. As you may have guessed, you can set the system’s default target with super user privileges via the systemctl set-target command.

The isolate command is handy for jumping between system targets. When this command is used along with a target name for an argument, all services and processes not enabled in the listed target are stopped. Any services and processes enabled and not running in the listed target are started. A snipped example is shown in Listing 6.15.

Listing 6.15: Jumping to a different target unit

# systemctl get-default
graphical.target
#
# systemctl isolate multi-user.target
#
# systemctl status graphical.target
[...]
   Active: inactive (dead) since Thu 2018-09-13 16:57:00 EDT; 4min 24s ago
     Docs: man:systemd.special(7)

Sep 13 16:54:41 localhost.localdomain systemd[1]: Reached target Graphical In...
Sep 13 16:54:41 localhost.localdomain systemd[1]: Starting Graphical Interface.
Sep 13 16:57:00 localhost.localdomain systemd[1]: Stopped target Graphical In[...]
Sep 13 16:57:00 localhost.localdomain systemd[1]: Stopping Graphical Interface.
[...]
#

In Listing 6.15, using super user privileges, the systemctl isolate command caused the system to jump from the default system target to the multi-user target. Unfortunately, there is no simple command to show your system’s current target in this case. However, the systemctl status command is useful. If you employ the command and give it the previous target’s name (graphical.target in this case), you should see that it is no longer active and thus not the current system target. Notice that a short history of the graphical target’s starts and stops is also shown in the status display.

Two extra special targets are rescue and emergency. These targets, sometimes called modes, are described here:

Rescue Target When you jump your system to the rescue target, the system mounts all the local filesystems, only the root user is allowed to log into the system, networking services are turned off, and only a few other services are started. The systemctl is-system-running command will return the maintenance status. Running disk utilities to fix corrupted disks is a useful task in this particular target.

Emergency Target When your system goes into emergency mode, the system only mounts the root filesystem, and it mounts it as read-only. Similar to rescue mode, it only allows the root user to log into the system, networking services are turned off, and only a few other services are started. The systemctl is-system-running command will return the maintenance status. If your system goes into emergency mode by itself, there are serious problems. This target is used for situations where even rescue mode cannot be reached.

Be aware that if you jump into either rescue or emergency mode, you’ll only be able to log into the root account. Therefore, you need to have the root account password. Also, your screen may go blank for a minute, so don’t panic. An example of jumping into emergency mode is shown in Listing 6.16.

Listing 6.16: Jumping to the emergency target unit

# systemctl isolate emergency
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue):
#
# systemctl is-system-running
maintenance
#
# systemctl list-units ––type=target
UNIT              LOAD     ACTIVE  SUB     DESCRIPTION
emergency.target  loaded   active  active  Emergency Mode
[...]
#
# systemctl default
#

In Listing 6.16, the systemctl command is employed to jump into emergency mode. Notice that you do not have to add the .target extension on the emergency target unit’s file name. This is true with all systemd targets. Once you reach emergency mode, you must enter the root password at the prompt. Once you reach the command line, you can enter commands listed in the welcome display or try some additional systemctl commands.

Notice in Listing 6.16 that when the systemctl is-system-running command is issued, the response is maintenance instead of running. Also, when the list-units command is employed, it shows that the emergency.target is active. The systemctl default command will cause the system to attempt to jump into the default target.

A handy systemd component is the systemd-analyze utility. With this utility, you can investigate your system’s boot performance and check for potential system initialization problems. Table 6.8 contains the more common commands you can use with the systemd-analyze utility.

Be aware that some of the longer systemd-analyze displays are piped into the less pager utility. You can turn that feature off by using the ––no-pager option. In Listing 6.17, using super user privileges, a few of these systemd-analyze commands are shown in action.

Listing 6.17: Employing the systemd-analyze utility

# systemd-analyze verify
#
# systemd-analyze verify sshd.service
#
# systemd-analyze time
Startup finished in 665ms (kernel) +
3.285s (initrd) + 58.319s (userspace) = 1min 2.269s
#
# systemd-analyze ––no-pager blame
         30.419s NetworkManager-wait-online.service
[...]
          4.848s kdump.service
          4.707s firewalld.service
          4.565s tuned.service
          4.390s libvirtd.service
          4.221s lvm2-monitor.service
[...]
           632ms NetworkManager.service
           607ms network.service
[...]
             9ms sys-kernel-config.mount
#

The first command used in Listing 6.17 allows you to check all your system’s unit files for problems. The second one only checks the sshd.service unit file. If you just receive a prompt back from those two commands, it indicates there were no errors found.

The third command in Listing 6.17 provides time information concerning your system’s initialization. Note that you could leave off the time keyword, and the systemd-analyze utility would still display the system initialization time because that is the default utility action.

The last command in Listing 6.17 employs the blame command. This display starts with those units that took the longest to initialize. At the bottom of the list are the units that initialized the fastest. It is a handy guide for troubleshooting initialization problems. Now if only you could use systemd-analyze blame to analyze your friends who are always late.

The systemd initialization approach is flexible and reliable for operating Linux systems and their services. The preceding sections provided an overview of the methods and commands for managing systemd initialized systems.

Understanding Runlevels

At system boot time, instead of targets to determine what groups of services to start, SysV init uses runlevels. These runlevels are defined in Table 6.9 and Table 6.10. Notice that different distributions use different runlevel definitions.

Note that runlevels 0 and 6 are not run levels by definition. Instead, they denote a transition from the current system state to the desired state. For example, a running system currently operating at runlevel 5 is transitioned to a powered-off state via runlevel 0.

To determine your system’s current and former runlevel, you employ the runlevel command. The first number or letter displayed indicates the previous runlevel (N indicates that the system is newly booted), and the second number indicates the current runlevel. An example is shown in Listing 6.18 of a newly booted Red Hat–based SysV init system, which is running at runlevel 5.

Listing 6.18: Employing the runlevel command

# runlevel
N 5
#

Instead of using a default target like systemd, SysV init systems employ a configuration file, /etc/inittab. This file used to start many different services, but in later years it only started terminal services and defined the default runlevel for a system. The file line defining the default runlevel is shown in Listing 6.19.

Listing 6.19: The /etc/inittab file line that sets the default runlevel

# grep :initdefault: /etc/inittab
id:5:initdefault:
#

Within Listing 6.19, notice the number 5 between the id: and the :initdefault: in the /etc/inittab file record. This indicates that the system’s default runlevel is 5. The initdefault is what specifies the runlevel to enter after the system boots.

Setting the default runlevel is the first step in configuring certain services to start at system initialization. Next, each service must have an initialization script located typically in the /etc/init.d/ directory. Listing 6.20 shows a snipped example of the various scripts in this directory. Note that the -1F options are used on the ls command to display the scripts in a single column and tack on a file indicator code. The * file indicator code denotes that these files are executable programs (Bash shell scripts in this case).

Listing 6.20: Listing script files in the /etc/init.d/ directory

# ls -1F  /etc/init.d/
anacron*
atd*
[...]
crond*
cups*
[...]
ntpd*
[...]
ypbind*
yum-updatesd*
#

These initialization scripts are responsible for starting, stopping, restarting, reloading, and displaying the status of various system services. The program that calls these initialization scripts is the rc script, and it can reside in either the /etc/init.d/ or /etc/rc.d/ directory. The rc script runs the scripts in a particular directory. The directory picked depends upon the desired runlevel. Each runlevel has its own subdirectory in the /etc/rc.d/ directory, as shown in Listing 6.21.

Listing 6.21: Runlevel subdirectories in the /etc/rc.d/ directory

# ls /etc/rc.d/
init.d  rc0.d  rc2.d  rc4.d  rc6.d     rc.sysinit
rc      rc1.d  rc3.d  rc5.d  rc.local
#

Notice in Listing 6.21 that there are seven subdirectories named rcn.d, where n is a number from 0 to 6. The rc script runs the scripts in the rcn.d subdirectory for the desired runlevel. For example, if the desired runlevel is 3, all the scripts in the /etc/rc.d/rc3.d/ directory are run. Listing 6.22 shows a snippet of the scripts in this directory.

Listing 6.22: Files in the /etc/rc.d/rc3.d directory

# ls -1F /etc/rc.d/rc3.d/
K01smolt@
K02avahi-dnsconfd@
K02NetworkManager@
[...]
K99readahead_later@
S00microcode_ctl@
S04readahead_early@
[...]
S55cups@
S99local@
S99smartd@
#

Notice in Listing 6.22 that the script names start with either a K or an S, are followed by a number, and then have their service name. The K stands for kill (stop), and the S stands for start. The number indicates the order in which this service should be stopped or started for that runlevel. This is somewhat similar to the After and Before directives in the systemd service type unit files.

The files in the /etc/rc.d/rcn.d/ directories are all symbolic links to the scripts in the /etc/init.d/ directory. Listing 6.23 shows an example of this.

Listing 6.23: Displaying the /etc/rc.d/rc3.d/S55cups link

# readlink -f /etc/rc.d/rc3.d/S55cups
/etc/rc.d/init.d/cups
#

The rc script goes through and runs all the K scripts first, passing a stop argument to each script. It then runs all the S scripts, passing a start argument to each script. This not only ensures that the proper services are started for a particular runlevel, it also allows jumping between runlevels after system initialization and thus stopping and starting certain services for that new runlevel.

Scripts are central to the SysV init process. To understand SysVinit scripts, be sure to read through Chapter 25 first. That chapter will help you understand Bash shell script basics, which in turn will help you to understand the SysV init script contents.

Investigating SysV init Commands

The various SysV init commands help in starting and stopping services, managing what services are deployed at various runlevels, and jumping between runlevels on an already running Linux system. We cover the various SysV init commands in this section.

Jumping between runlevels is a little different than jumping between systemd targets. It uses the init or telinit utilities to do so. These two utilities are essentially twins and can be interchanged for each other. To jump between runlevels on a SysV init system, the basic syntax is as follows:

init Destination-Runlevel
telinit Destination-Runlevel

Listing 6.24 shows an example of jumping on a SysV init system from the current runlevel 5 to the destination runlevel 3. Note that the runlevel command is employed to show the previous and current runlevels.

Listing 6.24: Jumping from runlevel 5 to runlevel 3

# runlevel
N 5
#
# init 3
#
# runlevel
5 3
#

To view a SysV init managed service’s status and control whether or not it is currently running, use the service utility. This utility has the following basic syntax:

service SCRIPT COMMAND [OPTIONS]

The SCRIPT in the service utility refers to a particular service script within the /etc/init.d/ directory. The service utility executes the script, passing it the designated COMMAND. Service scripts typically have the same name as the service. Also, you only have to provide a script’s base name and not the directory location. As an example, for the NTP service script, /etc/init.d/ntpd, you only need to use the ntpd base name.

Table 6.11 describes the various commonly used items you can employ for the COMMAND portion of the service utility. Keep in mind that if the COMMAND is not handled by the script or handled differently than it’s commonly handled, you’ll get an unexpected result.

It helps to see examples of the service utility in action. Listing 6.25 provides a few for your review.

Listing 6.25: Employing the service utility

# service httpd status
httpd is stopped
#
# service httpd start
Starting httpd:                        [  OK  ]
#
# service httpd status
httpd (pid 14124 14123 [...]) is running...
#
# service httpd stop
Stopping httpd:                        [  OK  ]
#
# service httpd status
httpd is stopped
#
# service ––status-all
anacron is stopped
atd (pid 2024) is running...
[...]
ypbind is stopped
yum-updatesd (pid 2057) is running...
#

The last service utility example in Listing 6.25 is worth pointing out. This command allows you to view all the services on your system along with their current status. Keep in mind that this list will scroll by quickly, so it’s a good idea to redirect its STDOUT to the less pager utility so you can view the display more comfortably.

To configure various services to start at different runlevels, there are two different commands you can use. The one you employ depends upon which distribution you are using. For Red Hat–based distros using SysV init, you’ll want to use the chkconfig utility. For Debian-based Linux distributions using SysV init, the update-rc.d program is the one to use.

The chkconfig utility has several different formats. They allow you to check what runlevels a service will start or not start on. Also, you can enable (start at system boot) or disable (not start at system boot) a particular service for a particular runlevel. Table 6.12 shows and describes these various commonly used chkconfig utility formats.

The first command in Table 6.12 can be a little confusing. Be aware that when the utility checks if the service is enabled at the current runlevel, a true or false is returned in the ? variable. Listing 6.26 shows an example of using this command and displaying the variable results.

Listing 6.26: Using the chkconfig utility to check service status

# runlevel
3 5
#
# chkconfig ––list sshd
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
#
# chkconfig sshd
# echo $?
0
# chkconfig ––list ntpd
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
#
# chkconfig ntpd
# echo $?
1
#

Notice in Listing 6.26 that the system’s current runlevel is 5. The sshd service is checked using the chkconfig ––list command, and you can see from the display that this service does start on runlevel 5, indicated by the 5:on shown. Therefore, the chkconfig sshd command should return a true. As soon as the command is entered and the prompt is returned, an echo $? command is entered. This displays a 0, which indicates a true was returned. Yes, 0 means true. That is confusing!

For the ntpd service in Listing 6.26, the service is not started at runlevel 5. Therefore, the chkconfig ntpd command returns a false, which is a 1.

To enable services at multiple runlevels, you’ll need to employ the ––level option. For this option, the runlevel numbers are listed one after the other with no delimiter in between. An example is shown in Listing 6.27.

Listing 6.27: Using the chkconfig utility to enable/disable services

# chkconfig ––list ntpd
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
#
# chkconfig ––level 35 ntpd on
#
# chkconfig ––list ntpd
ntpd            0:off   1:off   2:off   3:on    4:off   5:on    6:off
#
# chkconfig ––level 35 ntpd off
#
# chkconfig ––list ntpd
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
#

If you are using a Debian-based Linux SysV init distribution, instead of the chkconfig utility, you’ll need to employ the update-rc.d utility. It has its own set of options and arguments.

To start a program at the default runlevel, just use the following format:

update-rc.d service defaults

To remove the program from starting at the default runlevel, use the following format:

update-rc.d service remove

If you want to specify what runlevels the program starts and stops in, you’ll need to use the following format:

update-rc.d –f service start 40 2 3 4 5 . stop 80 0 1 6 .

The 40 and 80 specify the relative order within the runlevel when the program should start or stop (from 0 to 99). This allows you to customize exactly when specific programs are started or stopped during the boot sequence.

As you can see, managing the SysV init scripts and their associated runlevels can be tricky. However, if you have to take care of one of these systems, you now understand the tools that can help you.

Looking at systemd Mount Units

Distributions using systemd have additional options for persistently attaching filesystems. Filesystems can be specified either within the /etc/fstab file or within a mount unit file. A mount unit file provides configuration information for systemd to mount and control designated filesystems.

A single mount unit file is created for each mount point, and the file name contains the mount point’s absolute directory reference. However, the absolute directory reference has its preceding forward slash (/) removed, subsequent forward slashes are converted to dashes (-), and any trailing forward slash is removed. Mount unit file names also have a .mount extension. For example, the mount point, /home/temp/, would have a mount unit file named home-temp.mount.

A mount unit file’s contents mimic other systemd unit files, with a few special sections and options. In Listing 6.28, using the /home/temp/ mount point, an example mount unit file is shown.

Listing 6.28: Displaying an example systemd mount unit file

# cat /etc/systemd/system/home-temp.mount
[Unit]
Description=Test Mount Units

[Mount]
What=/dev/sdo1
Where=/home/temp
Type=ext4
Options=defaults
SloppyOptions=on
TimeOutSec=4

[Install]
WantedBy=multi-user.target
#

Notice that the file has the typical three sections for a unit file, with the middle section, [Mount], containing directives specific to mount type unit files. The What directive can use the device file name or a universally unique identifier (UUID), such as /dev/disk/by-uuid/UUID.

The SloppyOptions directive is helpful in that if set to on, it ignores any mount options not supported by a particular filesystem type. By default, it is set to off. Another helpful directive is the TimeOutSec. If the mount command does not complete by the number of designated seconds, the mount is considered a failed operation.

Be sure to include the [Install] section and set either the WantedBy or the RequiredBy directive to the desired target. If you do not do this, the filesystem will not be mounted upon a server boot.

You can manually mount and unmount the unit using the standard sytemctl utility commands. Listing 6.29 contains an example of deploying the home-temp.mount unit file.

Listing 6.29: Deploying a systemd mount unit file

# systemctl daemon-reload home-temp.mount
#
# systemctl start home-temp.mount
#
# ls /home/temp
lost+found
#

In Listing 6.29, the first command loads the newly configured mount unit file. The second command has systemd mount the filesystem using the home-temp.mount unit file. The second command is similar to how a service is started in that it uses the start command. While you don’t have to have the home-temp.mount argument and the command will work without it, a) the argument does add clarity/education to the situation being discussed and b) the argument prevents other services from being reloaded, which if other services were restarted could prove problematic.

To ensure that the filesystem is properly mounted, like a service unit, you use the systemctl utility to obtain a mounted filesystem’s status. An example is shown in Listing 6.30.

Listing 6.30: Checking a systemd mount unit’s status

# systemctl status home-temp.mount
• home-temp.mount - Test Mount Units
   Loaded: loaded (/etc/systemd/system/home-temp.mount; [...]
   Active: active (mounted) since Sat 2019-09-14 16:34:2[...]
    Where: /home/temp
     What: /dev/sdo1
  Process: 3990 ExecMount=/bin/mount /dev/sdo1 /home/temp[...]
[...]
#

There is one additional step required. To ensure that systemd will mount the filesystem persistently, the mount unit file must be enabled to start at boot, as other systemd units are enabled. An example is shown in Listing 6.31.

Listing 6.31: Enabling a systemd mount unit

# systemctl enable home-temp.mount
Created symlink from
/etc/systemd/system/multi-user.target.wants/home-temp.mount to
/etc/systemd/system/home-temp.mount.
#

This should all look very familiar! Keep in mind that you should only use mount unit files if you need to tweak the persistent filesystem configuration. If you do not, it’s best to use a /etc/fstab record to persistently mount the filesystem.

Exploring Automount Units

With systemd, you can also configure on-demand mounting as well as mounting in parallel using automount units. In addition, you can set filesystems to automatically unmount upon lack of activity.

An automount unit file operates similarly to a mount unit file. The naming convention is the same, except that the filename extension is .automount.

Within an automount unit file, for the [Automount] section, only the following three directives are available:

• Where
• DirectoryMode
• TimeOutIdleSec

The Where directive is required. It is configured the exact same way as it is in mount unit files. With this directive, you set the mount point.

The DirectoryMode directive is not a required option. This setting determines the permissions placed on any automatically created mount point and parent directories. By default it is set to the 0755 octal code.

The TimeOutIdleSec directive is also not required. This particular directive allows you to set the maximum amount of time (in seconds) a mounted filesystem can be idle. Once the time limit is reached, the filesystem is unmounted. By default this directive is disabled.