CONTROLLING

SERVICES AND
THE BOOT PROCESS
• GOAL
• Control and monitor network services, system daemons and the boot process using systemd.
• OBJECTIVES
• List system daemons and network services started by the systemd service and socket units.
• Control system daemons and network services, using systemctl.
• Describe the Red Hat Enterprise Linux boot process, set the default target used when
booting, and boot a system to a non-default target.
• Log into a system and change the root password when the current root password has been
lost.
• Manually repair file system configuration or corruption issues that stop the boot process.
• SECTIONS
• Identifying Automatically Started System Processes (and Guided Exercise)
• Controlling System Services (and Guided Exercise)
• Selecting the Boot Target (and Guided Exercise)
• Resetting the Root Password (and Guided Exercise)
• Repairing File System Issues at Boot (and Guided Exercise)
• LAB
• Controlling Services and the Boot Process
IDENTIFYING AUTOMATICALLY
STARTED SYSTEM PROCESSES
• The systemd daemon manages startup for Linux, including service startup and
service management in general. It activates system resources, server daemons,
and other processes both at boot time and on a running system.
• Daemons are processes that either wait or run in the background, performing
various tasks.
• Generally, daemons start automatically at boot time and continue to run until
shutdown or until they are manually stopped. It is a convention for names of
many daemon programs to end in the letter d.
• A service in the systemd sense often refers to one or more daemons, but starting
or stopping a service may instead make a one-time change to the state of the
system, which does not involve leaving a daemon process running afterward
(called oneshot).
systemd
• In Red Hat Enterprise Linux, the first process that starts (PID 1) is
systemd. A few of the features provided by systemd include:
• Parallelization capabilities (starting multiple services simultaneously),
which increase the boot speed of a system.
• On-demand starting of daemons without requiring a separate service.
• Automatic service dependency management, which can prevent long
timeouts. For example, a network-dependent service will not attempt
to start up until the network is available.
• A method of tracking related processes together by using Linux
control groups.
Systemd units
• systemd uses units to manage different types of objects. Some common unit types
are listed below:
• Service units have a .service extension and represent system services. This type of
unit is
• used to start frequently accessed daemons, such as a web server.
• Socket units have a .socket extension and represent inter-process communication
(IPC) sockets that systemd should monitor. If a client connects to the socket, systemd
will start a daemon and pass the connection to it. Socket units are used to delay the
start of a service at boot time and to start less frequently used services on demand.
• Path units have a .path extension and are used to delay the activation of a service
until a specific file system change occurs. This is commonly used for services which
use spool directories such as a printing system.
LISTING SERVICE UNITS
• use the systemctl command to explore the current state of the
system. For example, the following command lists all currently loaded
service units
Columns in the systemctl list-units
Command Output
• UNIT
• The service unit name.
• LOAD
• Whether systemd properly parsed the unit's configuration and loaded the unit into memory.
• ACTIVE
• The high-level activation state of the unit. This information indicates whether the unit has started
successfully or not.
• SUB
• The low-level activation state of the unit. This information indicates more detailed
informationabout the unit. The information varies based on unit type, state, and how the unit is
executed.
• DESCRIPTION
• The short description of the unit
• By default, the systemctl list-units --type=service command lists only
the service units with active activation states. The --all option lists all
service units regardless of the activation states. Use the --state=
option to filter by the values in the LOAD, ACTIVE, or SUB fields.
• The systemctl list-units command displays units that the systemd
service attempts to parse and load into memory; it does not display
installed, but not enabled, services. To see the state of all unit files
installed, use the systemctl list-unit-files command. For example:
VIEWING SERVICE STATES
• View the status of a specific unit with systemctl status name.type. If
the unit type is not provided, systemctl will show the status of a
service unit, if one exists.
Service Unit Information FIELD
• The meaning of the fields are:
Service States in the Output of systemctl
VERIFYING THE STATUS OF A
SERVICE
• use the following command to verify that the a service unit is
currently active (running):

• Run the following command to verify whether a service unit is

enabled to start automatically during system boot:

• To verify whether the unit failed during startup

exercise
CONTROLLING SYSTEM SERVICES
• To start a service, first verify that it is not running with systemctl
status. Then, use the systemctl start command as the root user (using
sudo if necessary). The example below shows how to start the
sshd.service service:

• To stop a currently running service, use the stop argument with the
systemctl command. The example below shows how to stop the
sshd.service service:
• restart of a running service, the service is stopped and then started.
On the restart of service, the process ID changes and a new process ID
gets associated during the startup

• Some services have the ability to reload their configuration files

without requiring a restart. This process is called a service reload.
Reloading a service does not change the process ID associated with
various service processes.
ENABLING SERVICES TO START OR
STOP AT BOOT
• Starting a service on a running system does not guarantee that the service
automatically starts when the system reboots.
• Similarly, stopping a service on a running system does not keep it from starting
again when the system reboots. To start a service at boot, use the systemctl
enable command.

• To verify whether the service is enabled or disable, use the systemctl is-
enabled command.
• To disable the service from starting automatically,
SUMMARY OF systemctl COMMANDS
exercise
SELECTING THE BOOT TARGET
The following list gives a high-level overview of the tasks involved for a physical
x86_64 system booting Red Hat Enterprise Linux 8
• The machine is powered on. The system firmware, either modern UEFI or older
BIOS, runs a Power On Self Test (POST) and starts to initialize some of the hardware.
• Configured using the system BIOS or UEFI configuration screens that you typically
reach by pressing a specific key combination, such as F2, early during the boot
process.
• The system firmware searches for a bootable device, either configured in the UEFI
boot firmware or by searching for a Master Boot Record (MBR) on all disks, in the
order configured in the BIOS.
• Configured using the system BIOS or UEFI configuration screens that you typically reach by
pressing a specific key combination, such as F2, early during the boot process.
Powerdeon

The system firmware, either modern UEFI or older BIOS, runs a

POST Power On Self Test (POST) and starts to initialize some of the hardware

System The system firmware searches for a bootable device, either by searching for
firmware a Master Boot Record (MBR) on all disks, or
(BIOS/UEIF) configured in the UEFI boot firmware in the order configured in the BIOS.

The boot loader hands control over to the kernel, passing in any options specified on
Bootloader the kernel command line in the boot loader, and the location of the initramfs in memory.
(GRUB2)

Kernel Important file locations

(intramfs) /boot
/boot/grub2/grub.cfg
/boot/intramfs-x.y.z
Systemd /boot/vmlinuz-x.y.z
/boot
(intramfs)
root file system Root file sysem /
/etc
/etc/fstab
/usr
Systemd /home
/var

Target
• The system firmware reads a boot loader from disk and then passes control of the
system to the boot loader. On a Red Hat Enterprise Linux 8 system, the boot loader is
the GRand Unified Bootloader version 2 (GRUB2).
• The boot loader hands control over to the kernel, passing in any options specified on
the kernel command line in the boot loader, and the location of the initramfs in
memory
• The kernel initializes all hardware for which it can find a driver in the initramfs, then
executes /sbin/init from the initramfs as PID 1. On Red Hat Enterprise Linux 8,
/sbin/init is a link to systemd.
• Configured using the kernel init= command-line parameter.
• The systemd instance from the initramfs executes all units for the initrd.target target.
This includes mounting the root file system on disk on to the /sysroot directory.
• Configured using /etc/fstab
• The kernel switches (pivots) the root file system from initramfs to the root
file system in /sysroot. systemd then re-executes itself using the copy of
systemd installed on the disk.
• systemd looks for a default target, either passed in from the kernel
command line or configured on the system, then starts (and stops) units to
comply with the configuration for that target, solving dependencies
between units automatically. In essence, a systemd target is a set of units
• that the system should activate to reach the desired state. These targets
typically start a textbased login or a graphical login screen.
• Configured using /etc/systemd/system/default.target and /etc/systemd/
system/.
REBOOTING AND SHUTTING DOWN
• To power off or reboot a running system from the command line, you
can use the systemctl command.
• systemctl poweroff stops all running services, unmounts all file
systems (or remounts them read-only when they cannot be
unmounted), and then powers down the system.
• systemctl reboot stops all running services, unmounts all file systems,
and then reboots the system.
• You can also use the shorter version of these commands, poweroff
and reboot, which are symbolic links to their systemctl equivalents.
SELECTING A SYSTEMD TARGET
• A systemd target is a set of systemd units that the system should start
to reach a desired state. The following table lists the most important
targets.
• To list the available targets, use the following command.

• administrators can switch to a different target using the systemctl

isolate command.
Setting a Default Target
• When the system starts, systemd activates the default.target target.
Normally the default target in /etc/systemd/system/ is a symbolic link
to either graphical.target or multiuser.target
Selecting a Different Target at Boot Time
• To select a different target at boot time, append the systemd.unit=target.target
option to the kernel command line from the boot loader.
1. Boot or reboot the system.
2. Interrupt the boot loader menu countdown by pressing any key (except Enter
which would initiate a normal boot).
3. Move the cursor to the kernel entry that you want to start.
4. Press e to edit the current entry.
5. Move the cursor to the line that starts with linux. This is the kernel command line.
6. Append systemd.unit=target.target. For example, systemd.unit=emergency.target.
7. Press Ctrl+x to boot with these changes.
exercise
RESETTING THE ROOT PASSWORD
• One task that every system administrator should be able to accomplish is
resetting a lost root password
• Several methods exist to set a new root password. A system administrator
could, for example, boot the system using a Live CD, mount the root file
system from there, and edit /etc/shadow.
• In this section, we explore a method that does not require the use of
external media.
• On Red Hat Enterprise Linux 8, it is possible to have the scripts that run
from the initramfs pause at certain points, provide a root shell, and then
continue when that shell exits. This is mostly meant for debugging, but you
can also use this method to reset a lost root password.
steps
1. Reboot the system.
2. Interrupt the boot loader countdown by pressing any key, except Enter.
3. Move the cursor to the kernel entry to boot.
4. Press e to edit the selected entry.
5. Move the cursor to the kernel command line (the line that starts with linux).
6. Append rd.break. With that option, the system breaks just before the system
hands control
1. from the initramfs to the actual system.
7. Press Ctrl+x to boot with the changes.
At this point, the system presents a root shell, with the actual root file system on the
disk mounted read-only on /sysroot.
Change root password
• Remount /sysroot as read/write.

• Switch into a chroot jail, where /sysroot is treated as the root of the
file-system tree.

• Set a new root password.

• Make sure that all unlabeled files, including /etc/shadow at this point,
get relabeled during boot.

• Type exit twice. The first command exits the chroot jail, and the
INSPECTING LOGS
• Looking at the logs of previously failed boots can be useful. If the
system journals are persistent across reboots, you can use the
journalctl tool to inspect those logs.
• by default, the system journals are kept in the /run/log/journal
directory, which means the journals are cleared when the system
reboots. To store journals in the / var/log/journal directory, which
persists across reboots, set the Storage parameter to persistent in
/etc/systemd/journald.conf.
Inspect the logs of a previous boot
• use the -b option of journalctl. Without any arguments, the -b option
only displays messages since the last boot. With a negative number as
an argument, it displays the logs of previous boots.
Using the Emergency and Rescue Targets
• By appending either systemd.unit=rescue.target or
systemd.unit=emergency.target to the kernel command line from the
boot loader, the system spawns into a rescue or emergency shell
instead of starting normally.
• Both of these shells require the root password.
• Administrators can use these shells to fix any issues that prevent the
system from booting normally; for example, a dependency loop
between services, or an incorrect entry in /etc/fstab.
• Exiting from these shells continues with the regular boot process.
exercise
DIAGNOSING AND FIXING FILE
SYSTEM ISSUES
• Errors in /etc/fstab and corrupt file systems can stop a system from
booting. In most cases, systemd drops to an emergency repair shell
that requires the root password.
• The following table lists some common errors and their results.
exercise