The RHEL web console is a Red Hat Enterprise Linux 8 web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment.

The RHEL web console enables you a wide range of administration tasks, including:

The RHEL web console uses the same system APIs as you would in a terminal, and actions performed in a terminal are immediately reflected in the RHEL web console.

You can monitor the logs of systems in the network environment, as well as their performance, displayed as graphs. In addition, you can change the settings directly in the web console or through the terminal.

To access the RHEL 8 web console, first enable the cockpit.socket service.

Red Hat Enterprise Linux 8 includes the RHEL 8 web console installed by default in many installation variants. If this is not the case on your system, install the cockpit package before enabling the cockpit.socket service.

Use the steps in this procedure for the first login to the RHEL web console using a system user name and password.

After successful authentication, the RHEL web console interface opens.

It is possible to connect to your web console interface from any client operating system and also from mobile phones or tablets.

If your system is part of an Identity Management (IdM) domain with enabled one-time password (OTP) configuration, you can use an OTP to log in to the RHEL web console.

You can use the web console to restart a RHEL system that the web console is attached to.

You can use the web console to shut down a RHEL system that the web console is attached to.

You can set a time zone and synchronize the system time with a Network Time Protocol (NTP) server.

You can use the web console to join the Red Hat Enterprise Linux 8 system to the Identity Management (IdM) domain.

Disable Simultaneous Multi Threading (SMT) in case of attacks that misuse CPU SMT. Disabling SMT can mitigate security vulnerabilities, such as L1TF or MDS.

After the system restart, the CPU no longer uses SMT.

Companies or agencies sometimes need to show a warning that usage of the computer is for lawful purposes, the user is subject to surveillance, and anyone trespassing will be prosecuted. The warning must be visible before login. Similarly to SSH, the web console can optionally show the content of a banner file on the login screen. To enable banners in your web console sessions, you need to modify the /etc/cockpit/cockpit.conf file. Note that the file is not required and you may need to create it manually.

By default, there is no idle timeout set in the web console interface. If you wish to enable an idle timeout on your system, you can do so by modifying the /etc/cockpit/cockpit.conf configuration file. Note that the file is not required and you may need to create it manually.

The host name identifies the system. By default, the host name is set to localhost, but you can change it.

A host name consists of two parts:

A host name with an attached domain name is called a fully qualified domain name (FQDN). For example: mymachine.example.com.

Host names are stored in the /etc/hostname file.

You can configure a pretty host name in the RHEL web console. The pretty host name is a host name with capital letters, spaces, and so on.

The pretty host name displays in the web console, but it does not have to correspond with the host name.

This procedure sets the real host name or the pretty host name in the web console.

The cockpit package is a part of Red Hat Enterprise Linux 8 by default. To be able to use add-on applications you must install them separately.

The following table lists available add-on applications for the RHEL 8 web console.

Red Hat Enterprise Linux 8 provides several performance profiles that optimize the system for the following tasks:

The tuned service optimizes system options to match the selected profile.

In the web console, you can set which performance profile your system uses.

This procedure uses the web console to optimize the system performance for a selected task.

RHEL System Roles is a collection of Ansible roles and modules. RHEL System Roles provide a configuration interface to remotely manage multiple RHEL systems. The interface enables managing system configurations across multiple versions of RHEL, as well as adopting new major releases.

On Red Hat Enterprise Linux 8, the interface currently consists of the following roles:

All these roles are provided by the rhel-system-roles package available in the AppStream repository.

You can find the following terms across this documentation:

The following procedure describes how to apply a particular role.

Accurate timekeeping is important for a number of reasons. In Red Hat Enterprise Linux, timekeeping is ensured by the NTP protocol, which is implemented by a daemon running in user space. The user-space daemon updates the system clock running in the kernel. The system clock can keep time by using various clock sources.

Red Hat Enterprise Linux 8 uses the chronyd daemon to implement NTP. chronyd is available from the chrony package. For more information, see Using the chrony suite to configure NTP.

System-wide locale settings are stored in the /etc/locale.conf file, which is read at early boot by the systemd daemon. Every service or user inherits the locale settings configured in /etc/locale.conf, unless individual programs or individual users override them.

This section describes how to manage system locale.

The keyboard layout settings control the layout used on the text console and graphical user interfaces.

This section describes how to change the system language using the desktop GUI.

Follow the steps in this procedure to configure your network and host name.

This procedure describes adding an Ethernet connection with the following settings using the nmcli utility:

The nmtui application provides a text user interface to NetworkManager. This procedure describes how to add a new connection profile.

In the web console, the Networking menu enables you:

Figure 1.1. Managing Networking in the RHEL 8 web console

You can configure the networking connections on multiple target machines using the network role.

The network role allows to configure the following types of interfaces:

The required networking connections for each host are provided as a list within the network_connections variable.

The following example shows how to apply the network role to ensure that an Ethernet connection with the required parameters exists:

# SPDX-License-Identifier: BSD-3-Clause
---
- hosts: network-test
  vars:
    network_connections:

      # Create one ethernet profile and activate it.
      # The profile uses automatic IP addressing
      # and is tied to the interface by MAC address.
      - name: prod1
        state: up
        type: ethernet
        autoconnect: yes
        mac: "00:00:5e:00:53:00"
        mtu: 1450

  roles:
    - rhel-system-roles.network

For more information on applying a system role, see Introduction to RHEL System Roles.

Use the following procedure to register your system if you have not registered it during the installation process already.

Use the following steps to register a newly installed Red Hat Enterprise Linux using the RHEL 8 web console.

At this point, your Red Hat Enterprise Linux 8 system has been successfully registered.

Follow the steps in this procedure to enroll your system with your Red Hat account.

Follow the steps in this procedure to register your system with an activation key. You can get the activation key from your organization administrator.

You can determine which services are enabled or disabled at boot time already during the installation process. You can also enable or disable a service on an installed operating system.

This section describes the steps for enabling or disabling those services on an already installed operating system:

# systemctl unmask service_name

This section describes how you can also enable or disable a service using the web console. You can manage systemd targets, services, sockets, timers, and paths. You can also check the service status, start or stop services, enable or disable them.

A firewall is a network security system that monitors and controls incoming and outgoing network traffic according to configured security rules. A firewall typically establishes a barrier between a trusted secure internal network and another outside network.

The firewalld service, which provides a firewall in Red Hat Enterprise Linux, is automatically enabled during installation.

Security-Enhanced Linux (SELinux) is an additional layer of system security that determines which processes can access which files, directories, and ports. These permissions are defined in SELinux policies. A policy is a set of rules that guide the SELinux security engine.

This section provides an overview of user accounts and groups. The following are the different types of user accounts:

This section describes basic command-line tools to manage user accounts and groups.

With user accounts displayed in the RHEL web console you can:

The RHEL web console displays all user accounts located in the system. Therefore, you can see at least one user account just after the first login to the web console.

After logging into the RHEL web console, you can perform the following operations:

Use the following steps for adding user accounts to the system and setting administration rights to the accounts through the RHEL web console.

kdump is a service providing a crash dumping mechanism. The service enables you to save the contents of the system’s memory for later analysis. kdump uses the kexec system call to boot into the second kernel (a capture kernel) without rebooting; and then captures the contents of the crashed kernel’s memory (a crash dump or a vmcore) and saves it. The second kernel resides in a reserved part of the system memory.

The procedure below shows you how to use the Kernel Dump tab in the Red Hat Enterprise Linux web console interface to configure the amount of memory that is reserved for the kdump kernel. The procedure also describes how to specify the target location of the vmcore dump file and how to test your configuration.

RHEL System Roles is a collection of Ansible roles and modules that provide a consistent configuration interface to remotely manage multiple RHEL systems. The kdump role enables you to set basic kernel dump parameters on multiple systems.

The following example playbook shows how to apply the kdump system role to set the location of the crash dump files:

---
- hosts: kdump-test
  vars:
    kdump_path: /var/crash
  roles:
    - rhel-system-roles.kdump

Use the following steps to install the packages for using the Relax-and-Recover (ReaR) utility, create a rescue system, configure and generate a backup.

The following two services handle syslog messages:

The systemd-journald daemon collects messages from various sources and forwards them to Rsyslog for further processing. The systemd-journald daemon collects messages from the following sources:

The Rsyslog service sorts the syslog messages by type and priority and writes them to the files in the /var/log directory. The /var/log directory persistently stores the log messages.

The following subdirectories under the /var/log directory store syslog messages.

Follow the steps in this procedure to inspect the log files using the web console.

Figure 1.2. Inspecting the log files in the RHEL 8 web console

The Journal is a component of systemd that helps to view and manage log files. It addresses problems connected with traditional logging, closely integrated with the rest of the system, and supports various logging technologies and access management for the log files.

You can use the journalctl command to view messages in the system journal using the command line, for example:

$ journalctl -b | grep kvm
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
...

The following section describes how to use the Red Hat Customer Portal to get help.

The sosreport command collects configuration details, system information and diagnostic information from a Red Hat Enterprise Linux system.

The following section describes how to use the sosreport command to produce reports for your support cases.

Note that you can filter the results by appending global expressions as arguments. See Section 2.3.6, “Specifying global expressions in yum input” for more details.

Note that you can filter the results by passing the ID or name of repositories as arguments or by appending global expressions. See Section 2.3.6, “Specifying global expressions in yum input” for more details.

Note that you can filter the results by appending global expressions as arguments. See Section 2.3.6, “Specifying global expressions in yum input” for more details.

Note that you can filter the results by appending global expressions as arguments. See Section 2.7.4, “Specifying global expressions in yum input” for more details.

yum commands allow you to filter the results by appending one or more glob expressions as arguments. Global expressions must be escaped when passed as arguments to the yum command. To ensure global expressions are passed to yum as intended, use one of the following methods:

Note that you can optimize the package search by explicitly defining how to parse the argument. See Section 2.4.3, “Specifying a package name in yum input” for more details.

To optimize the installation and removal process, you can append -n, -na, or -nerva suffixes to yum install and yum remove commands to explicitly define how to parse an argument:

To check and download package updates automatically and regularly, you can use the DNF Automatic tool that is provided by the dnf-automatic package.

DNF Automatic is an alternative command-line interface to yum that is suited for automatic and regular execution using systemd timers, cron jobs and other such tools.

DNF Automatic synchronizes package metadata as needed and then checks for updates available. After, the tool can perform one of the following actions depending on how you configure it:

The outcome of the operation is then reported by a selected mechanism, such as the standard output or email.

# systemctl enable dnf-automatic-download.timer

# systemctl start dnf-automatic-download.timer

# systemctl enable dnf-automatic-install.timer

# systemctl start dnf-automatic-install.timer

# systemctl enable dnf-automatic-notifyonly.timer

# systemctl start dnf-automatic-notifyonly.timer

# systemctl enable dnf-automatic.timer

# systemctl start dnf-automatic.timer

Note that you can optimize the package search by explicitly defining how to parse the argument. See Section 2.6.3, “Specifying a package name in yum input” for more details.

To optimize the installation and removal process, you can append -n, -na, or -nerva suffixes to yum install and yum remove commands to explicitly define how to parse an argument:

Note that you can filter the results by appending global expressions as arguments. See Section 2.7.4, “Specifying global expressions in yum input” for more details.

yum commands allow you to filter the results by appending one or more glob expressions as arguments. Global expressions must be escaped when passed as arguments to the yum command. To ensure global expressions are passed to yum as intended, use one of the following methods:

Note that the yum history undo command only reverts the steps that were performed during the transaction. If the transaction installed a new package, the yum history undo command uninstalls it. If the transaction uninstalled a package, the yum history undo command reinstalls it. yum history undo also attempts to downgrade all updated packages to their previous versions, if the older packages are still available.

Note that the yum history redo command only repeats the steps that were performed during the transaction.

yum commands allow you to filter the results by appending one or more glob expressions as arguments. Global expressions must be escaped when passed as arguments to the yum command. To ensure global expressions are passed to yum as intended, use one of the following methods:

The /etc/yum.conf configuration file contains the [repository] sections, where repository is a unique repository ID. The [repository] sections allows you to define individual yum repositories.

For a complete list of available [repository] options, see the [repository] OPTIONS section of the yum.conf(5) manual page.

To define a new repository, you can:

The /etc/yum.conf configuration file contains one [main] section. The key-value pairs in this section affect how yum operates and treats repositories.

You can add additional options under the [main] section heading in /etc/yum.conf.

For a complete list of available [main] options, see the [main] OPTIONS section of the yum.conf(5) manual page.

yum provides plug-ins that extend and enhance its operations. Certain plug-ins are installed by default.

The following section describes how to enable, configure, and disable yum plug-ins.

The systemd system and service manager provides the following main features:

The systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to Red Hat Enterprise Linux 6 system that used SysV init:

For a detailed list of compatibility changes introduced with systemd, see the Migration Planning Guide for Red Hat Enterprise Linux 7.

To list all currently loaded service units, type the following at a shell prompt:

systemctl list-units --type service

For each service unit file, this command displays its full name (UNIT) followed by a note whether the unit file has been loaded (LOAD), its high-level (ACTIVE) and low-level (SUB) unit file activation state, and a short description (DESCRIPTION).

By default, the systemctl list-units command displays only active units. If you want to list all loaded units regardless of their state, run this command with the --all or -a command line option:

systemctl list-units --type service --all

You can also list all available service units to see if they are enabled. To do so, type:

systemctl list-unit-files --type service

For each service unit, this command displays its full name (UNIT FILE) followed by information whether the service unit is enabled or not (STATE). For information on how to determine the status of individual service units, see Displaying service status.

$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
…​
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'

$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
…​
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

To display detailed information about a service unit that corresponds to a system service, type the following at a shell prompt:

systemctl status name.service

Replace name with the name of the service unit you want to inspect (for example, gdm). This command displays the name of the selected service unit followed by its short description, one or more fields described in Table 3.5, “Available service unit information”, and if it is executed by the root user, also the most recent log entries.

To only verify that a particular service unit is running, run the following command:

systemctl is-active name.service

Similarly, to determine whether a particular service unit is enabled, type:

systemctl is-enabled name.service

Note that both systemctl is-active and systemctl is-enabled return an exit status of 0 if the specified service unit is running or enabled. For information on how to list all currently loaded service units, see Listing services.

# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno…​
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r…​

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

To start a service unit that corresponds to a system service, type the following at a shell prompt as root:

systemctl start name.service

Replace name with the name of the service unit you want to start (for example, gdm). This command starts the selected service unit in the current session. For information on how to enable a service unit to be started at boot time, see Enabling a service. For information on how to determine the status of a certain service unit, see Displaying service status.

# systemctl start httpd.service

To stop a service unit that corresponds to a system service, type the following at a shell prompt as root:

systemctl stop name.service

Replace name with the name of the service unit you want to stop (for example, bluetooth). This command stops the selected service unit in the current session. For information on how to disable a service unit and prevent it from being started at boot time, see Disabling a service. For information on how to determine the status of a certain service unit, see Displaying service status.

# systemctl stop bluetooth.service

To restart a service unit that corresponds to a system service, type the following at a shell prompt as root:

systemctl restart name.service

Replace name with the name of the service unit you want to restart (for example, httpd). This command stops the selected service unit in the current session and immediately starts it again. Importantly, if the selected service unit is not running, this command starts it too. To tell systemd to restart a service unit only if the corresponding service is already running, run the following command as root:

systemctl try-restart name.service

Certain system services also allow you to reload their configuration without interrupting their execution. To do so, type as root:

systemctl reload name.service

Note that system services that do not support this feature ignore this command altogether. For convenience, the systemctl command also supports the reload-or-restart and reload-or-try-restart commands that restart such services instead. For information on how to determine the status of a certain service unit, see Displaying service status.

# systemctl reload httpd.service

To configure a service unit that corresponds to a system service to be automatically started at boot time, type the following at a shell prompt as root:

systemctl enable name.service

Replace name with the name of the service unit you want to enable (for example, httpd). This command reads the [Install] section of the selected service unit and creates appropriate symbolic links to the /usr/lib/systemd/system/name.service file in the /etc/systemd/system/ directory and its subdirectories. This command does not, however, rewrite links that already exist. If you want to ensure that the symbolic links are re-created, use the following command as root:

systemctl reenable name.service

This command disables the selected service unit and immediately enables it again. For information on how to determine whether a certain service unit is enabled to start at boot time, see Displaying service status. For information on how to start a service in the current session, see Starting a service.

# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

To prevent a service unit that corresponds to a system service from being automatically started at boot time, type the following at a shell prompt as root:

systemctl disable name.service

Replace name with the name of the service unit you want to disable (for example, bluetooth). This command reads the [Install] section of the selected service unit and removes appropriate symbolic links to the /usr/lib/systemd/system/name.service file from the /etc/systemd/system/ directory and its subdirectories. In addition, you can mask any service unit to prevent it from being started manually or by another service. To do so, run the following command as root:

systemctl mask name.service

This command replaces the /etc/systemd/system/name.service file with a symbolic link to /dev/null, rendering the actual unit file inaccessible to systemd. To revert this action and unmask a service unit, type as root:

systemctl unmask name.service

For information on how to determine whether a certain service unit is enabled to start at boot time, see Displaying service status. For information on how to stop a service in the current session, see Stopping a service.

# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

In systemd, positive and negative dependencies between services exist. Starting particular service may require starting one or more other services (positive dependency) or stopping one or more services (negative dependency).

When you attempt to start a new service, systemd resolves all dependencies automatically. Note that this is done without explicit notification to the user. If you are already running a service, and you attempt to start another service with a negative dependency, the first service is automatically stopped.

For example, if you are running the postfix service, and you try to start the sendmail service, systemd first automatically stops postfix, because these two services are conflicting and cannot run on the same port.

The previous versions of Red Hat Enterprise Linux were distributed with SysV init or Upstart, and implemented a predefined set of runlevels that represented specific modes of operation. These runlevels were numbered from 0 to 6 and were defined by a selection of system services to be run when a particular runlevel was enabled by the system administrator. Starting with Red Hat Enterprise Linux 7, the concept of runlevels has been replaced with systemd targets.

Red Hat Enterprise Linux 7 was distributed with a number of predefined targets that are more or less similar to the standard set of runlevels from the previous releases. For compatibility reasons, it also provides aliases for these targets that directly maps to the SysV runlevels.

The following table provides a complete list of SysV runlevels and their corresponding systemd targets:

The following table compares the SysV init commands with systemctl. Use the systemctl utility to view, change, or configure systemd targets:

The default target unit is represented by the /etc/systemd/system/default.target file.

By default, the systemctl list-units command displays only active units.

The default target unit is represented by the /etc/systemd/system/default.target file. The following procedure describes how to change the default target by using the systemctl command:

The following procedure describes how to change the default target by creating a symbolic link to the target.

This procedure explains how to change the target unit in the current session using the systemctl command.

Replace multi-user with the name of the target unit you want to use by default.

Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a regular booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time.

Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts a few essential services.

The systemctl utility provides commands for shutting down the system, however the traditional shutdown command is also supported. Although the shutdown command will call the systemctl utility to perform the shutdown, it has an advantage in that it also supports a time argument. This is particularly useful for scheduled maintenance and to allow more time for users to react to the warning that a system shutdown has been scheduled. The option to cancel the shutdown can also be an advantage.

Using systemctl commands

To shut down the system and power off the machine, type the following at a shell prompt as root:

systemctl poweroff

To shut down and halt the system without powering off the machine, run the following command as root:

systemctl halt

By default, running either of these commands causes systemd to send an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run the selected command with the --no-wall command line option, for example:

systemctl --no-wall poweroff

Using the shutdown command

To shut down the system and power off the machine at a certain time, use a command in the following format as root:

shutdown --poweroff hh:mm

Where hh:mm is the time in 24 hour clock format. The /run/nologin file is created 5 minutes before system shutdown to prevent new logins. When a time argument is used, an optional message, the wall message, can be appended to the command.

To shut down and halt the system after a delay, without powering off the machine, use a command in the following format as root:

shutdown --halt +m

Where +m is the delay time in minutes. The now keyword is an alias for +0.

A pending shutdown can be canceled by the root user as follows:

shutdown -c

See the shutdown(8) manual page for further command options.

To restart the system, run the following command as root:

systemctl reboot

By default, this command causes systemd to send an informative message to all users that are currently logged into the system. To prevent systemd from sending this message, run this command with the --no-wall command line option:

systemctl --no-wall reboot

To suspend the system, type the following at a shell prompt as root:

systemctl suspend

This command saves the system state in RAM and with the exception of the RAM module, powers off most of the devices in the machine. When you turn the machine back on, the system then restores its state from RAM without having to boot again. Because the system state is saved in RAM and not on the hard disk, restoring the system from suspend mode is significantly faster than restoring it from hibernation, but as a consequence, a suspended system state is also vulnerable to power outages.

For information on how to hibernate the system, see Section 3.4.4, “Hibernating the system”.

To hibernate the system, type the following at a shell prompt as root:

systemctl hibernate

This command saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system then restores its state from the saved data without having to boot again. Because the system state is saved on the hard disk and not in RAM, the machine does not have to maintain electrical power to the RAM module, but as a consequence, restoring the system from hibernation is significantly slower than restoring it from suspend mode.

To hibernate and suspend the system, run the following command as root:

systemctl hybrid-sleep

For information on how to suspend the system, see Section 3.4.3, “Suspending the system”.

A unit file contains configuration directives that describe the unit and define its behavior. Several systemctl commands work with unit files in the background. To make finer adjustments, system administrator must edit or create unit files manually. Table 3.1, “Systemd unit files locations” lists three main directories where unit files are stored on the system, the /etc/systemd/system/ directory is reserved for unit files created or customized by the system administrator.

Unit file names take the following form:

unit_name.type_extension

Here, unit_name stands for the name of the unit and type_extension identifies the unit type, see Table 3.2, “Available systemd unit types” for a complete list of unit types. For example, there usually is sshd.service as well as sshd.socket unit present on your system.

Unit files can be supplemented with a directory for additional configuration files. For example, to add custom configuration options to sshd.service, create the sshd.service.d/custom.conf file and insert additional directives there. For more information on configuration directories, see Modifying existing unit files.

Also, the sshd.service.wants/ and sshd.service.requires/ directories can be created. These directories contain symbolic links to unit files that are dependencies of the sshd service. The symbolic links are automatically created either during installation according to [Install] unit file options or at runtime based on [Unit] options. It is also possible to create these directories and symbolic links manually. For more details on [Install] and [Unit] options, see the tables below.

Many unit file options can be set using the so called unit specifiers – wildcard strings that are dynamically replaced with unit parameters when the unit file is loaded. This enables creation of generic unit files that serve as templates for generating instantiated units. See Working with instantiated units for details.

Unit files typically consist of three sections:

There are several use cases for creating unit files from scratch: you could run a custom daemon, create a second instance of some existing service (as in Creating a second instance of the sshd service), or import a SysV init script (more in Converting SysV init scripts to unit files). On the other hand, if you intend just to modify or extend the behavior of an existing unit, use the instructions from Modifying existing unit files. The following procedure describes the general process of creating a custom service.

Before taking time to convert a SysV init script to a unit file, make sure that the conversion was not already done elsewhere. All core services installed on Red Hat Enterprise Linux come with default unit files, and the same applies for many third-party software packages.

Converting an init script to a unit file requires analyzing the script and extracting the necessary information from it. Based on this data you can create a unit file. As init scripts can vary greatly depending on the type of the service, you might need to employ more configuration options for translation than outlined in this chapter. Note that some levels of customization that were available with init scripts are no longer supported by systemd units.

The majority of information needed for conversion is provided in the script’s header. The following example shows the opening section of the init script used to start the postfix service on Red Hat Enterprise Linux 6:

!/bin/bash # postfix Postfix Mail Transfer Agent # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf  BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # END INIT INFO

In the above example, only lines starting with # chkconfig and # description are mandatory, so you might not find the rest in different init files. The text enclosed between the BEGIN INIT INFO and END INIT INFO lines is called Linux Standard Base (LSB) header. If specified, LSB headers contain directives defining the service description, dependencies, and default runlevels. What follows is an overview of analytic tasks aiming to collect the data needed for a new unit file. The postfix init script is used as an example.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

Services installed on the system come with default unit files that are stored in the /usr/lib/systemd/system/ directory. System Administrators should not modify these files directly, therefore any customization must be confined to configuration files in the /etc/systemd/system/ directory.

It is possible to instantiate multiple units from a single template configuration file at runtime. The "@" character is used to mark the template and to associate units with it. Instantiated units can be started from another unit file (using Requires or Wants options), or with the systemctl start command. Instantiated service units are named the following way:

template_name@instance_name.service

Where template_name stands for the name of the template configuration file. Replace instance_name with the name for the unit instance. Several instances can point to the same template file with configuration options common for all instances of the unit. Template unit name has the form of:

unit_name@.service

For example, the following Wants setting in a unit file:

Wants=getty@ttyA.service getty@ttyB.service

first makes systemd search for given service units. If no such units are found, the part between "@" and the type suffix is ignored and systemd searches for the getty@.service file, reads the configuration from it, and starts the services.

For example, the getty@.service template contains the following directives:

[Unit]
Description=Getty on %I
…​
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
…​

When the getty@ttyA.service and getty@ttyB.service are instantiated from the above template, Description= is resolved as Getty on ttyA and Getty on ttyB.

To examine system boot performance, you can use the systemd-analyze command. This command has many options available. However, this section covers only the selected ones that may be important for systemd tuning in order to shorten the boot time.

For a complete list and detailed description of all options, see the systemd-analyze man page.

$ systemctl list-unit-files --state=enabled

Analyzing overall boot time

$ systemd-analyze

Analyzing unit initialization time

$ systemd-analyze blame

The output lists the units in descending order according to the time they took to initialize during the last successful boot.

Identifying critical units

$ systemd-analyze critical-chain

The output highlights the units that critically slow down the boot with the red color.

Figure 3.1. The output of the systemd-analyze critical-chain command

If you find the boot time of your system long, you can shorten it by disabling some of the services enabled on boot by default.

To list such services, run:

$ systemctl list-unit-files --state=enabled

To disable a service, run:

# systemctl disable service_name

However, certain services must stay enabled in order that your operating system is safe and functions in the way you need.

You can use the table below as a guide to selecting the services that you can safely disable. The table lists all services enabled by default on a minimal installation of Red Hat Enterprise Linux 8, and for each service it states whether this service can be safely disabled.

The table also provides more information about the circumstances under which the service can be disabled, or the reason why you should not disable the service.

To find more information about a service, you can run one of the following commands:

$ systemctl cat <service_name>

$ systemctl help <service_name>

The systemctl cat command provides the content of the service file located under /usr/lib/systemd/system/<service>, as well as all applicable overrides. The applicable overrides include unit file overrides from the /etc/systemd/system/<service> file or drop-in files from a corresponding unit.type.d directory.

For more information on drop-in files, see the systemd.unit man page.

The systemctl help command shows the man page of the particular service.