RHCSA EX200

Chapter 04

Operate running systems, including booting into

different run levels, identifying processes,
starting and stopping virtual machines, and
controlling services
This chapter describes the following major topics:
✓ Boot, reboot, and shut down a system normally
✓ Start, stop, and check the status of network services
✓ Start and stop services and configure services to start
automatically at boot
✓ Configure systems to boot into a specific target automatically
✓ Configure network services to start automatically at boot
✓ Configure virtual machines
 RHCSA EX200

S ystemd is a system and service manager for Linux operating

systems. When run as first process on boot (as PID 1), it acts as init
system that brings up and maintains userspace services. Separate
instances are started for logged-in users to start their services.
systemd is usually not invoked directly by the user, but is installed as the
/sbin/init symlink and started during early boot. The user manager
instances are started automatically through the user@.service(5)
service.
It employs the concepts of units and targets for initialization, service
administration, and state changes. A good grasp of what unit and target
configuration files store is key to understanding how systemd operates.
Alerts and messages generated by system services and user activities are
forwarded to predefined locations for storage. These alerts and
messages include those that are produced during system boot time.
The log data may be analyzed for debugging or auditing purposes. Log
files grow over time and need to be rotated periodically to prevent the
file system space from filling up. There are configuration files that define
the default and custom locations to direct the log messages to and to
configure rotation settings. The system log file records custom messages
sent to it. systemd includes a service for viewing and managing system
logs in addition to the traditional logging service. This service maintains
a log of runtime activities for faster retrieval and can be configured to
store the information permanently.

System Initialization and Service Management:

systemd (short for system daemon) is the system initialization and
service management mechanism.
It has fast-tracked system initialization and state transitioning by
introducing features such as parallel processing of startup
 RHCSA EX200

scripts, improved handling of service dependencies, and on demand

activation of services.
Moreover, it supports snapshotting of system states, tracks processes
using control groups, and automatically maintains mount points.
systemd is the first process with PID 1 that spawns at boot and it is the
last process that terminates at shutdown.
During the operational state, systemd maintains the sockets and uses
them to reconnect other daemons and services that were interacting
with an old instance of a daemon before that daemon was terminated
or restarted.

Units
Units are systemd objects used for organizing boot and maintenance
tasks, such as hardware initialization, socket creation, file system
mounts, and service startups.

Unit configuration is stored in their respective configuration files, which

are auto-generated from other configurations, created dynamically
from the system state, produced at runtime, or user-developed.

Units are in one of several operational states, including active, inactive,

in the process of being activated or deactivated, and failed. Units can be
enabled or
disabled. An enabled unit can be started to an active state; a disabled
unit cannot be started.

Units have a name and a type, and they are encoded in files with names
in the form unitname.type. Some examples are tmp.mount,
sshd.service, syslog.socket, and umount.target.

There are two types of unit configuration files:

 RHCSA EX200

(1) systemunit files that are distributed with installed packages and
located in the /usr/lib/systemd/system directory, and

(2) user unit files that are user-defined and stored in the
/etc/systemd/user directory.

Tips:

Use ls -l command on both directories to list their contents.

[user1@Server1 ~]$ ls -l /usr/lib/systemd/system
total 1792
-rw-r--r--. 1 root root 729 Jan 15 2021 accounts-daemon.service
-rw-r--r--. 1 root root 502 Jan 8 2021 alsa-restore.service
-rw-r--r--. 1 root root 465 Jan 8 2021 alsa-state.service
-rw-r--r--. 1 root root 739 May 27 2020 anaconda-direct.service
-rw-r--r--. 1 root root 274 Jan 19 2021 anaconda-fips.service
-rw-r--r--. 1 root root 240 Nov 8 2018 anaconda-nm-config.service
-rw-r--r--. 1 root root 660 Nov 8 2018 anaconda-noshell.service
-rw-r--r--. 1 root root 585 Feb 2 2021 anaconda-pre.service
-rw-r--r--. 1 root root 442 Nov 8 2018 anaconda.service
…………………………………

[user1@Server1 ~]$ ls -l /etc/systemd/user

total 0
lrwxrwxrwx. 1 root root 34 Sep 3 12:07 dbus-org.bluez.obex.service ->
/usr/lib/systemd/user/obex.service
drwxr-xr-x. 2 root root 32 Sep 3 12:07 default.target.wants
drwxr-xr-x. 2 root root 65 Sep 12 20:32 sockets.target.wants

This information can be vetted with the pkg-config command:

[user1@Server1 ~]$ pkg-config systemd --variable=systemdsystemconfdir

/etc/systemd/system

[user1@Server1 ~]$ pkg-config systemd --variable=systemduserconfdir

/etc/systemd/user
 RHCSA EX200

Furthermore, there are additional system units that are created at

runtime and destroyed when they are no longer needed. They are
located in the /run/systemd/system directory. These runtime unit files
take precedence over the system unit files, and the user unit files take
priority over the runtime files.

Types of Units:
Systemd categories units according to the type of resource they
describe. The easiest way to determine the type of a unit is with its type
suffix, which is appended to the end of the resource name. The
following list describes the types of units available to systemd:
 RHCSA EX200

Unit files contain common and specific configuration elements.

Common elements fall under the [Unit] and [Install] sections, and
comprise the description, documentation location, dependency
information, conflict information, and other options that are
independent of the type of unit.

Example:

A sample unit file for sshd.service is shown below from the

/usr/lib/systemd/system directory:

[user1@Server1 ~]$ cat /usr/lib/systemd/system/sshd.service

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target
[user1@Server1 ~]$
 RHCSA EX200

Targets
Targets are simply logical collections of units. They are a special
systemd unit type with the .target file extension. Targets are used to
execute a series of units. systemd includes several predefined targets
that are described below:

Target unit files contain all information under the [Unit] section, and it
comprises the description, documentation location, and dependency
and conflict information.
 RHCSA EX200

Example:

[user1@Server1 ~]$ cat /usr/lib/systemd/system/graphical.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=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
[user1@Server1 ~]$

The file shows four dependencies: Requires, Wants, Conflicts, and After.
It suggests that the system must have already accomplished the
rescue.service, rescue.target, multiuser. target, and display-
manager.service levels in order to be declared running in the graphical
target.

Tip: run man systemd.target for details on systemd targets.

 RHCSA EX200

The systemctl Command

systemd comes with a set of management tools for querying and
controlling operations. The primary tool for interaction in this command
suite is systemctl. The systemctl command performs administrative
functions and supports plentiful subcommands and flags.
 RHCSA EX200

Listing and Viewing Units

The systemctl command is used to view and manage all types of units.
To list all units that are currently loaded in memory along with their
status and description, run the systemctl command without any options
or subcommands.
 RHCSA EX200

You can also execute the following command:

$ systemctl list-unit-files
To list all unit files (column 1) installed on the system and their current
state (column 2).
 RHCSA EX200

By default, the systemctl command lists only the active units. You can
use the --all option to include the inactive units too. To list all (--all) active
and inactive services of type (-t) service:

To list all units that failed (--failed) to start at the last system boot:

[user1@Server1 ~]$ systemctl –failed

 RHCSA EX200

To list the hierarchy of all dependencies (required and wanted units) for
the current default target:

$ systemctl list-dependencies
 RHCSA EX200

To list the hierarchy of all dependencies (required and wanted units) for
a specific unit such as sshd.service:

$ systemctl list-dependencies sshd.service

 RHCSA EX200

Managing Service Units

The systemctl command offers several subcommands to manage service
units, including starting, stopping, restarting, and checking their status.
These and other management operations are summarized below:
To check the current operational status and other details for the
sshd.service:
$ systemctl status sshd.service

An activation status designates the current state of the service. Possible

states include:
Active (running): The service is running with one or more processes
Active (exited): Completed a one-time configuration
Active (waiting): Running but waiting for an event
Inactive: Not running
Activating: In the process of being activated
Deactivating: In the process of being deactivated
Failed: If the service crashed or could not be started
To disable the sshd service from auto starting at the next system reboot:
[root@Server1 ~]# systemctl disable sshd.service
Removed /etc/systemd/system/multi-user.target.wants/sshd.service.
To enable the sshd service from auto starting at the next system reboot:
[root@Server1 ~]# systemctl enable sshd.service
 RHCSA EX200

To check whether atd is set to auto start at the next system reboot:
[root@Server1 ~]# systemctl is-enabled sshd.service
enabled
To check whether the atd service is running:
[root@Server1 ~]# systemctl is-active sshd.service
active
To stop, start and restart atd, run either of the following:
[root@Server1 ~]# systemctl stop sshd.service; systemctl start
sshd.service
[root@Server1 ~]# systemctl restart sshd.service
To show the details of the sshd service:
# systemctl show sshd.service
 RHCSA EX200

Managing Target Units

The systemctl command is also used to manage the target units. It can
be used to view or change the default boot target, switch from one
running target into another, and so on.
To view what units of type (-t) target are currently loaded and active:

For each target unit, the above output returns the target unit’s name,
load state, high-level and low-level activation states, and a short
description. Add the --all option to the above to see all loaded targets in
either active or inactive state.
 RHCSA EX200

[root@Server1 ~]#
[root@Server1 ~]# systemctl -t target | grep active
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
cryptsetup.target loaded active active Local Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
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-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
rpc_pipefs.target loaded active active rpc_pipefs.target
rpcbind.target loaded active active RPC Port Mapper
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
timers.target loaded active active Timers
25 loaded units listed. Pass --all to see loaded but inactive units, too.
[root@Server1 ~]#
 RHCSA EX200

System Logging
System logging (syslog for short) is one of the most rudimentary
elements of an operating system. Its purpose is to capture messages
generated by the kernel, daemons, commands, user activities,
applications, and other events, and forwarded them to various log files,
which store them for security auditing, service malfunctioning, system
troubleshooting, or informational purposes.

The daemon that is responsible for system logging is called rsyslogd

(rocket-fast system for log processing). This service daemon is multi-
threaded, with support for enhanced filtering, encryption-protected
message relaying, and a variety of configuration options.

The rsyslogd daemon reads its configuration file /etc/rsyslog.conf and

the configuration files located in the /etc/rsyslog.d directory at startup.
The default depository for most system log files is the /var/log directory.
Other services such as audit, Apache, and GNOME desktop manager
have subdirectories under /var/log for storing their respective log files.

The rsyslog service is modular, allowing the modules listed in its

configuration file to be dynamically loaded in the kernel as and when
needed. Each module brings a new functionality to the system upon
loading.

The rsyslogd daemon can be stopped manually using systemctl stop

rsyslog. Replace stop with start, restart, reload, and status as
appropriate.
 RHCSA EX200

Log files are a critical component of your server infrastructure.

Sysadmins use log files to accomplish many tasks:

• Troubleshooting
• Service Level Agreement (SLA) audits
• Baselining
• Preventative maintenance

Configuration file
The actual rsyslog configuration is managed via a configuration file in the
/etc directory. Back up the original configuration file, and then open the
/etc/rsyslog.conf file with your favorite text editor.
 RHCSA EX200

The Boot Log File

Logs generated during the system startup display the service startup
sequence with a status showing whether the service was started
successfully. This information may help in any post-boot
troubleshooting if required. Boot logs are stored in the boot.log file
under /var/log.

OK or FAILED within the square brackets indicates if the service was

started successfully or not.

The System Log File

The default location for storing most system activities, as defined in the
rsyslog.conf file, is the /var/log/messages file.
This file saves log information in plain text format and may be viewed
with any file display utility, such as cat, more, pg, less, head, or tail. This
file may be observed in real time using the tail command with the -f
switch.
The messages file captures the date and time of the activity, hostname
of the system, name and PID of the service, and a short description of
the event being logged.
 RHCSA EX200

The systemd Journal

In addition to the rsyslog service, RHEL offers a systemd based logging
service for the collection and storage of logging data. This service is
implemented via the systemd journald daemon.

The function of this service is to gather, store, and display logging

events from a variety of sources such as the kernel, rsyslog and other
services, initial RAM disk, and alerts generated during the early boot
stage. It stores these messages in the binary format in files called
journals that are located in the /run/log/journal directory.
 RHCSA EX200

Notice that the format of the messages is similar to that of the events
logged to the /var/log/messages file.
Each line begins with a timestamp followed by the system hostname,
process name with or without a PID, and the actual message.
To display detailed output for each entry, use the -o verbose option:
# journalctl -o verbose
 RHCSA EX200

To view all events since the last system reboot, use the -b options:
# journalctl -b

To reveal all messages for a particular system unit, such as sshd.service:

Lab - 1: Modify Default Boot Target

As user1 with sudo on server1, modify the default boot target from
graphical to multi-user, and reboot the system to test it. Run the
systemctl and who commands after the reboot for validation. Restore
the default boot target back to graphical and reboot to verify. (Hint:
System Initialization and Service Management).
 RHCSA EX200

Boot, reboot, and shut down a system normally

To reboot the system, choose one command among these:
# reboot
# systemctl reboot
# shutdown -r now
# init 6
# telinit 6
To shutdown the system, choose one command among these:
# halt
# systemctl halt
# shutdown -h now
# init 0
# telinit 0
To switch off the system, choose one command among these:
# poweroff
# systemctl poweroff