Red Hat SummitUsing systemd unit files to customize and optimize your system
Optimize system performance and extend configuration with systemd
Abstract
Providing feedback on Red Hat documentation
We are committed to providing high-quality documentation and value your feedback. To help us improve, you can submit suggestions or report errors through the Red Hat Jira tracking system.
Procedure
Log in to the Jira website.
If you do not have an account, select the option to create one.
- Click Create in the top navigation bar.
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the window.
Chapter 1. Working with systemd unit files
To perform tasks for managing your system resources, you can configure the systemd unit files to create custom unit files, modify existing unit files, and work with instantiated units.
1.1. Introduction to unit files
To manage units and their resources, you can use unit files. Several systemctl commands work with unit files in the background. A unit file is the .service or .target file on your hard drive that has configuration directives to describe the unit and define its properties.
The basic object that systemd manages is a systemd unit, a representation of system resources and services. A systemd unit consists of a name, type and a configuration file that defines and manages a particular task. You can use unit files to configure system behavior. Examples of various systemd unit types are as follows:
- Service : Controls and manages individual system services.
- Target : Represents a group of units that define system states.
- Device : Manages hardware devices and their availability.
- Mount : Handles file system mounting.
- Timer : Schedules tasks to run at specific intervals.
You can edit or create unit files manually. Three main directories contain unit files on the system:
-
/usr/lib/systemd/system/-systemdunit files distributed with installed RPM packages. -
/run/systemd/system/-systemdunit files created at run time. -
/etc/systemd/system/-systemdunit files created by using thesystemctl enablecommand and unit files added for extending a service.
The /etc/systemd/system/ directory is reserved for unit files created or customized by a system administrator.
Unit file naming convention is as follows:
<unit_name>.<type_extension>
In this example, <unit_name> stands for the name of the unit and <type_extension> identifies the unit type. For example, you can find sshd.service and sshd.socket units present on your system.
For additional configurations, you can use systemd drop-in files.
Create the
sshd.service.d/directory and edit thecustom.conffile.# mkdir -p /etc/systemd/system/sshd.service.dCreate a drop-in file:
# touch /etc/systemd/system/sshd.service.d/custom.confEdit the service with the
custom.confdrop-in file:# systemctl edit sshd.serviceThe
systemctl editcommand opens thesshd.serviceunit file in the default text editor.You can add additional directives to the file. For example, to add a custom configuration option to
sshd.service, add the following line to the file:[Service] ExecStart= ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd_config.custom
The system uses systemd to manage the sshd.service dependencies through the directories /etc/systemd/system/sshd.service.wants/ and /etc/systemd/system/sshd.service.requires/. These directories are for symlinks to other services that the SSH daemon needs or wants to start. While systemd does not create these directories directly, you can use the systemctl enable <service> command to automatically add the necessary links. systemd creates the symbolic links automatically either during installation according to the [Install] section options or at runtime based on the [Unit] section options from the unit file.
With unit specifiers, you can set many unit file options. Unit specifiers are wildcard strings that the system dynamically replaces with unit parameters when it loads the unit file. This feature enables you to create unit files that serve as templates for generating instantiated units.
1.2. Systemd unit files locations
You can find the unit configuration files in the mentioned directories.
| Directory | Description |
|---|---|
|
|
|
|
|
|
|
|
|
The default configuration of systemd is defined during the compilation and you can find the configuration in the /etc/systemd/system.conf file. By editing this file, you can modify the default configuration by overriding values for systemd units globally.
For example, to override the default value of the timeout limit, which is set to 90 seconds, use the DefaultTimeoutStartSec parameter to input the required value in seconds:
DefaultTimeoutStartSec=_required value_1.3. Unit file structure
Unit files consist of three main sections that define unit behavior, type-specific directives, and installation information. Understanding this structure helps you to create and change systemd units effectively.
[Unit]section- Contains generic options that do not depend on the type of the unit. These options provide a unit description, specify the unit’s behavior, and set dependencies to other units.
- [<unit_type>] section
-
Contains type-specific directives, which are grouped under a section named after the unit type. For example, service unit files contain the
[Service]section. [Install]section-
Contains information about unit installation that the
systemctl enableandsystemctl disablecommands use
1.4. Important [Unit] section options
The [Unit] section has generic options that are not dependent on the type of the unit. These options have a unit description, specify the unit’s behavior, and set dependencies to other units.
| Option [a] | Description |
|---|---|
|
|
A meaningful description of the unit. This text is displayed for example in the output of the |
|
| Provides a list of URIs referencing documentation for the unit. |
|
|
Defines the order in which units are started. The unit starts only after the units specified in |
|
|
Configures dependencies on other units. The units listed in |
|
|
Configures weaker dependencies than |
|
|
Configures negative dependencies, an opposite to |
[a]
For a complete list of options configurable in the [Unit] section, see the systemd.unit(5) manual page.
[b]
In most cases, it is sufficient to set only the ordering dependencies with After and Before unit file options. If you also set a requirement dependency with Wants (suggested) or Requires, the ordering dependency still needs to be specified. That is because ordering and requirement dependencies work independently from each other.
| |
1.5. Important [Service] section options
To manage configuration parameters that define how the service operates and interacts with the system, use the [Service] section. Each systemd service unit has a [Service] section that includes directives for this unit type.
| Option [a] | Description |
|---|---|
|
|
Configures the unit process startup type that affects the functionality of
|
|
|
Specifies commands or scripts to run when the unit starts. |
|
| Specifies commands or scripts to run when the unit stops. |
|
| Specifies commands or scripts to run when the unit reloads. |
|
|
When you enable this option, the service restarts after its process exits, with the exception of a clean stop by the |
|
|
If you set this to True, the service remains active even when all its processes exit. Default is False. This option is especially useful if you configure |
[a]
For a complete list of options configurable in the [Service] section, see the systemd.service(5) man page.
| |
1.6. Important [Install] section options
The [Install] section has information about unit installation used by systemctl enable and disable commands.
| Option [a] | Description |
|---|---|
|
|
Provides a space-separated list of additional names for the unit. Most |
|
|
A list of units that depend on the unit. When this unit is enabled, the units listed in |
|
|
A list of units that weakly depend on the unit. When this unit is enabled, the units listed in |
|
| Specifies a list of units to be installed or uninstalled along with the unit. |
|
| Limited to instantiated units, this option specifies the default instance for which the unit is enabled. See Working with instantiated units. |
[a]
For a complete list of options configurable in the [Install] section, see the systemd.unit(5) manual page.
| |
1.7. Creating custom unit files
To modify properties of an existing unit or create a new unit from scratch, you need to create custom unit files.
There are several use cases for creating unit files from scratch: you could run a custom daemon or create a second instance of some existing service as in Creating a custom unit file by using the second instance of the sshd service
However, to modify or extend the properties of an existing unit, use the instructions from Modifying existing unit files.
Prerequisites
- To create a custom service, prepare the executable file with the service. The file can contain a custom-created script, or an executable delivered by a software provider.
-
To manage custom services, prepare a PID file to hold a constant PID for the main process of the custom service. You can also include environment files to store shell variables for the service. Make sure the source script is executable (by executing the
chmod a+x) and is not interactive. - You have administrative privileges.
Procedure
Create a unit file in the
/etc/systemd/system/directory:# touch /etc/systemd/system/<name>.serviceApply the read-only permission to the unit file:
# chmod 664 /etc/systemd/system/<name>.serviceReplace <name> with a name of the service you want to create.
Open the created
<name>.servicefile, and add the service configuration options. You can use various options depending on the type of service you need to create, see Unit file structure.The following is an example unit configuration for a network-related service:
[Unit] Description=<service_description> After=network.target [Service] ExecStart=<path_to_executable> Type=forking PIDFile=<path_to_pidfile> [Install] WantedBy=default.target-
<service_description> is an informative description that is displayed in journal log files and in the output of the
systemctl statuscommand. -
The
Aftersetting ensures that the service is started only after the network is running. Add a space-separated list of other relevant services or targets. - path_to_executable stands for the path to the actual service executable.
-
Type=forkingis used for daemons that make the fork system call. The main process of the service is created with the PID specified in path_to_pidfile. Find other startup types in Important [Service] section options. -
WantedBystates the target or targets that the service should be started under. Think of these targets as a replacement of the older concept of runlevels.
-
<service_description> is an informative description that is displayed in journal log files and in the output of the
Notify
systemdthat a new<name>.servicefile exists:# systemctl daemon-reload # systemctl start <name>.serviceImportantAlways run the
systemctl daemon-reloadcommand after creating new unit files or modifying existing unit files. Otherwise, thesystemctl startorsystemctl enablecommands could fail due to a mismatch between states ofsystemdand actual service unit files on disk. On systems with a large number of units, this can take a long time as the state of each unit is serialized and subsequently deserialized during the reload.
1.8. Creating a custom unit file by using the second instance of the sshd service
To configure and run multiple instances of a service, you can create copies of the original service configuration files. Then, modify certain parameters to avoid conflicts with the primary instance of the service.
Prerequisites
- You have administrative privileges.
-
You have installed the
sshdservice.
Procedure
Create a copy of the
sshd_configfile that the second daemon will use:# cp /etc/ssh/sshd_config /etc/ssh/sshd-second_configEdit the
sshd-second_configfile created in the last step to assign a different port number and PID file to the second daemon:Port 22220 PidFile /var/run/sshd-second.pidSee the
sshd_config (5)man page forPortandPidFileoptions. Make sure the requested port is not in use by any other service. The PID file does not have to exist before running the service, it is generated automatically on service start.Create a copy of the
systemdunit file for thesshdservice:# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.serviceEdit the created
sshd-second.servicefile:Modify the
Descriptionoption:# vi /etc/systemd/system/sshd-second.serviceDescription=OpenSSH server second instance daemonAdd
sshd.serviceto services specified in theAfteroption, so that the second instance starts only after the first one has already started:After=syslog.target network.target auditd.service sshd.service-
Remove the
ExecStartPre=/usr/sbin/sshd-keygenline, the first instance ofsshdincludes key generation. Add the
-f /etc/ssh/sshd-second_configparameter to thesshdcommand, so that the alternative configuration file is used:ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONSAfter the modifications, the
sshd-second.serviceunit file contains the following settings:[Unit] Description=OpenSSH server second instance daemon After=syslog.target network.target auditd.service sshd.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
If using SELinux, add the port for the second instance of
sshdto SSH ports, otherwise the second instance ofsshdwill be rejected to bind to the port:# semanage port -a -t ssh_port_t -p tcp 22220Enable
sshd-second.serviceto start automatically on boot:# systemctl enable --now sshd-second.service
Verification
Verify if the
sshd-second.serviceis running by using thesystemctl statuscommand.# systemctl status sshd-second.serviceVerify if the port is enabled by connecting to the second instance of
sshd:$ ssh -p 22220 user@serverMake sure you configure the firewall to allow connections to the second instance of
sshd.
1.9. Finding the systemd service descriptions and dependencies
To discover the service descriptions and dependencies, you can use the systemctl show <example_service_name> command. You can also list the dependencies by using the systemctl list-dependencies <example_service_name> command.
To find the description of the service, you can use the line starting with #description. Use this description together with the service name in the Description option in the [Unit] section of the unit file. The header might contain similar data on the #Short-Description and #Description lines.
To find the dependencies of the service, you can use the Linux standard base (LSB) header. It might contain several directives that form dependencies between services.
# grep -i "Required-Start\|Required-Stop\|Default-Start\|Default-Stop" /etc/init.d/<example_service_name>Most of them are translatable to systemd unit options, see the following table:
| LSB Option | Equivalent Unit File | Description |
|---|---|---|
|
|
| Include negative dependencies. |
|
|
| Specifies the boot facility name of the service, that can be referenced in other init scripts (with the "$" prefix). This is no longer needed as unit files refer to other units by their file names. |
|
|
|
Includes boot facility names of required services. This is translated as an ordering dependency, boot facility names are replaced with unit file names of corresponding services or targets they belong to. For example, in case of |
|
|
| Includes weaker dependencies than Required-Start. Failed Should-Start dependencies do not affect the service startup. |
1.10. Finding default targets of the service
To decide the default systemd targets in which a service should start, check for lines such as #chkconfig or #Default-Start in the service script or Linux Standard Base (LSB) header.
The runlevels correspond to default systemd targets. In systemd, runlevels 2, 3, and 5 map to multi-user.target and graphical.target, while runlevel 4 maps to a custom or user defined target. Specify these targets in the WantedBy option in the [Install] section of your unit file to control when the service starts by default. Because graphical.target depends on multi-user.target, you can also specify only graphical.target for services meant to run in a graphical environment. Also, examine #Default-Stop to identify targets to stop the service by default. The other two values specified on the #chkconfig line represent startup and shutdown priorities of the init script. These values are interpreted by systemd if it loads the init script, but there is no unit file equivalent.
1.11. Finding files used by the service
You need to review the init script or systemd unit file to find files used by a service. Look for references of configuration files, environment files, PID files, and executables in the init script or systemd unit file.
-
In traditional init scripts, check for lines that load function libraries, source configuration files, or specify environment and PID files (often mentioned as
#configand#pidfilein the header). -
In systemd unit files, check options such as
EnvironmentFile=for environment configurations andPIDFile=for PID files. TheExecStart=,ExecStartPre=, and other related directives show executables or scripts the service calls. - Additionally, review paths and filenames mentioned in these scripts and directives to identify all files that the service uses during its operation.
The init script header does not include the path to the executable program and other dependent files required by the service. In previous versions of Red Hat Enterprise Linux, init scripts used a Bash case statement to define the behavior of the service on default actions, such as start, stop, or restart, and custom-defined actions. The following excerpt from the example_service init script shows the block of code executed at service start.
conf_check() {
[ -x /usr/sbin/myservice ] || exit 5
[ -d /etc/myservice ] || exit 6
[ -d /var/spool/myservice ] || 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 myservice: "
make_aliasesdb >/dev/null 2>&1
[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
/usr/sbin/myservice start 2>/dev/null 1>&2 && success || failure $"$prog start"
RETVAL=$?
[ $RETVAL -eq 0 ] && touch $lockfile
echo
return $RETVAL
}
The extensibility of the init script allowed specifying two custom functions, conf_check() and make_aliasesdb() are called from the start() function block. Several external files and directories are mentioned: the /usr/sbin/myservice main executable program, the /etc/myservice/ and /var/spool/myservice/ configuration directories, and the /usr/sbin/postconf/ directory.
The systemd unit file supports only the predefined actions, but enables executing custom executables with ExecStart, ExecStartPre, ExecStartPost, ExecStop, and ExecReload options. The /usr/sbin/myservice together with supporting scripts are executed on service start.
Converting complex init scripts requires understanding the purpose of every statement in the script. Some of the statements are specific to the operating system version, therefore you do not need to convert them. However, some adjustments required for the new environment, both in the unit file and in the executable program and supporting files.
1.12. Modifying existing unit files
To customize and optimize services for your specific needs without creating a new configuration from scratch, you can modify an existing unit file. If you want to modify existing unit files, proceed to the /etc/systemd/system/ directory.
Do not modify the unit files in the /usr/lib/systemd/system/ directory.
Prerequisites
- You have administrative privileges.
Procedure
-
Create a directory for supplementary configuration files at
/etc/systemd/system/<unit>.d/. You can extend the default configuration with additional functionality, while still referring to the original unit file. Changes to the default unit introduced with a package upgrade are therefore applied automatically. For details, see Extending the default unit configuration. Create a copy of the original unit file from
/usr/lib/systemd/system/directory in the/etc/systemd/system/directory and make changes there. The copy overrides the original file, therefore changes introduced with the package update are not applied. This method is useful for making significant unit changes that should persist regardless of package updates. For details, see Overriding the default unit configuration.-
To return to the default configuration of the unit, delete custom-created configuration files and the
/etc/systemd/system/<unit>.d/drop-in directory. Apply changes to unit files:
# systemctl daemon-reloadThe
daemon-reloadoption reloads all unit files and recreates the entire dependency tree, which is needed to immediately apply any change to a unit file.If the modified unit file belongs to a running service, restart the service:
# systemctl restart <name>.serviceImportantTo modify a service properties, such as dependencies or timeouts, that is handled by a SysV initscript, do not modify the initscript. Instead, create a
systemddrop-in configuration file for the service as described in: Extending the default unit configuration and Overriding the default unit configuration.To manage the service in the same way as a normal systemd service, create a new directory
/etc/systemd/system/network.service.d/and a systemd drop-in file/etc/systemd/system/network.service.d/<example_config.conf>. Then, put the modified values into the drop-in file.The
systemdservice identifies thenetworkservice asnetwork.service, so the created directory must be named asnetwork.service.d.
-
To return to the default configuration of the unit, delete custom-created configuration files and the
1.13. Extending the default unit configuration
To extend the default unit file with additional systemd configuration options, you can create a configuration directory in the /etc/systemd/system/ directory.
Prerequisites
- You have administrative privileges.
Procedure
Create a configuration directory in
/etc/systemd/system/:# mkdir /etc/systemd/system/<name>.service.d/Replace <name> with the name of the service you want to extend. The syntax applies to all unit types.
Create a configuration file with the .conf suffix:
# touch /etc/systemd/system/name.service.d/<config_name>.confReplace <config_name> with the name of the configuration file. This file adheres to the normal unit file structure and you have to specify all directives in the appropriate sections, see Unit file structure.
For example, to add a custom dependency, create a configuration file with the following content:
[Unit] Requires=<new_dependency> After=<new_dependency>The <new_dependency> stands for the unit to be marked as a dependency. Another example is a configuration file that restarts the service after its main process exited, with a delay of 30 seconds:
[Service] Restart=always RestartSec=30Create small configuration files focused only on one task. Such files can be easily moved or linked to configuration directories of other services.
Apply changes to the unit:
# systemctl daemon-reload# systemctl restart <name>.serviceTo automatically execute a custom shell script when starting the Apache service, modify the
httpd.serviceunit.Create a directory and a custom configuration file:
# mkdir /etc/systemd/system/httpd.service.d/# touch /etc/systemd/system/httpd.service.d/custom_script.confSpecify the script you want to execute after the main service process by inserting the following text to the
custom_script.conffile:[Service] ExecStartPost=/usr/local/bin/custom.shApply the unit changes::
# systemctl daemon-reload# systemctl restart httpd.serviceNoteThe configuration files from the
/etc/systemd/system/configuration directories take precedence over unit files in/usr/lib/systemd/system/. Therefore, if the configuration files contain an option that can be specified only once, such asDescriptionorExecStart, the default value of this option is overridden. Note that in the output of thesystemd-deltacommand, described in Monitoring overridden units, such units are always marked as[EXTENDED], even though in sum, certain options are actually overridden.
1.14. Overriding the default unit configuration
To make persistent changes to the unit file configuration after updating the package that provides the unit file, you can override the default unit configuration.
Prerequisites
- You have administrative privileges.
Procedure
Copy the unit file to the
/etc/systemd/system/directory:# cp /usr/lib/systemd/system/<name>.service /etc/systemd/system/<name>.serviceReplace <name> with the name of the service you want to override.
- Open the copied file and make changes.
Apply unit changes:
# systemctl daemon-reloadRestart the service:
# systemctl restart <name>.service
1.15. Changing the timeout limit
To prevent a malfunctioning service from freezing the system, you can specify a timeout value per service. Otherwise, the default value for timeout is 90 seconds for normal services and 300 seconds for SysV-compatible services.
Prerequisites
- You have administrative privileges.
Procedure
Edit the
httpdunit file:# systemctl edit httpdSpecify the
TimeoutStartSecvalue in the[Service]section:... [Service] ... PrivateTmp=true TimeoutStartSec=10 [Install] WantedBy=multi-user.target ...Reload the
systemddaemon:# systemctl daemon-reload
Verification
Verify the new timeout value:
# systemctl show httpd -p TimeoutStartUSecNoteTo change the timeout limit globally, input the
DefaultTimeoutStartSecin the/etc/systemd/system.conffile.
1.16. Monitoring overridden units
To monitor overridden or modified unit files, you can use the systemd-delta command.
Prerequisites
- You have administrative privileges.
Procedure
Display an overview of overridden or modified unit files:
# systemd-delta[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service --- /usr/lib/systemd/system/autofs.service 2014-10-16 21:30:39.000000000 -0400 +++ /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500 @@ -8,7 +8,8 @@ EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid ExecReload=/usr/bin/kill -HUP $MAINPID -TimeoutSec=180 +TimeoutSec=240 +Restart=Always [Install] WantedBy=multi-user.target [MASKED] /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service [EXTENDED] /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf 4 overridden configuration files found.
1.17. Working with instantiated units
To manage multiple instances of a service, you can use a single template configuration. You can define a generic template, denoted by @, for a unit and generate multiple instances of that unit with specific parameters at runtime. By using Requires or Wants options or the systemctl start command, you can start instantiated units from another unit file.
<template_name>@<instance_name>.serviceThe <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
With this command, systemd searches 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 has 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=Getty on %I is resolved as Getty on ttyA and Getty on ttyB.
1.18. Important unit specifiers
You can use the wildcard characters, called unit specifiers, in any unit configuration file. Unit specifiers substitute certain unit parameters and are interpreted at runtime.
| Unit Specifier | Meaning | Description |
|---|---|---|
|
| Full unit name |
Stands for the full unit name including the type suffix. |
|
| Prefix name | Stands for a unit name with type suffix removed. For instantiated units %p stands for the part of the unit name before the "@" character. |
|
| Instance name |
Is the part of the instantiated unit name between the "@" character and the type suffix. |
|
| Hostname | Stands for the hostname of the running system at the point in time the unit configuration is loaded. |
|
| Runtime directory |
Represents the runtime directory, which is either |
For a complete list of unit specifiers, see the systemd.unit(5) man page on your system.
Chapter 2. Managing system services with systemctl
To administer system level services, use the systemctl utility. You can interact with systemd by enabling control of services and units. With systemctl, you can manage states of system services, list available services, and display status of system services.
2.1. Listing system services
To optimize system performance, you can use the systemctl command to list and review system services. System services handle background processes, manage hardware, and supports core system functionality.
Prerequisites
- You have administrative privileges.
Procedure
List all currently loaded service units:
$ systemctl list-units --type serviceUNIT LOAD ACTIVE SUB DESCRIPTION abrt-ccpp.service loaded active exited Install ABRT coredump hook abrt-oops.service loaded active running ABRT kernel 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, or a 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'By default, the
systemctl list-unitscommand displays only active units. For each service unit file, the command provides an overview of the following parameters:UNIT- The full name of the service unit
LOAD- The load state of the configuration file
ACTIVEorSUB- The current high-level and low-level unit file activation state
DESCRIPTION- A short description of the unit’s purpose and functionality
List all loaded units regardless of their state:
$ systemctl list-units --type service --allList the status, for example
enabledordisabled, of all available service units:$ systemctl list-unit-files --type serviceUNIT FILE STATE abrt-ccpp.service enabled abrt-oops.service enabled abrtd.service enabled ... wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed.For each service unit, this command displays:
-
UNIT FILE: The full name of the service unit -
STATE: The information whether the service unit is enabled or disabled to start automatically during boot
-
2.2. Displaying system service status
To inspect any service unit to get detailed information and verify the state of the service, use the systemctl command. Status information includes whether the service unit is running, enabled to start during boot, or masked.
You can also view services that are scheduled to start after or before a particular service unit. See the following table for the available service unit information.
| Field | Description |
|---|---|
|
| Information whether the service unit has been loaded, the absolute path to the unit file, and a note whether the unit is enabled to start during boot. |
|
| Information whether the service unit is running followed by a timestamp. |
|
| The process ID and the name of the corresponding system service. |
|
| Additional information about the corresponding system service. |
|
| Additional information about related processes. |
|
|
Additional information about related control groups ( |
You can use the following commands to display system service status:
Display detailed information about a service unit that corresponds to a system service:
$ systemctl status <name>.serviceReplace <name> with the name of the service unit you want to inspect, for example,
gdm.This command displays the following information:
- The name of the selected service unit followed by a short description
-
The execution of the service unit, if the unit is executed by the
rootuser - The most recent log entries
- Detailed information about the service unit
Verify that a particular service unit is running:
$ systemctl is-active <name>.serviceDecide whether a particular service unit is enabled to start during boot time:
$ systemctl is-enabled <name>.serviceBoth
systemctl is-activeandsystemctl is-enabledcommands return an exit status of0if the specified service unit is running or enabled.Check which services systemd scheduled to start before the specified service unit:
# systemctl list-dependencies --after <name>.serviceFor example, to view the list of services ordered to start before
gdm, enter:# 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 ...Check what services systemd orders to start after the specified service unit:
# systemctl list-dependencies --before <name>.serviceFor example, to view the list of services systemd orders to start after
gdm, enter:# systemctl list-dependencies --before gdm.servicegdm.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 ...
2.3. Starting and stopping a systemd unit
To start or stop a system service in the current session, you can use the systemctl command.
Prerequisites
- You have administrative privileges.
Procedure
To start or stop a system service:
# systemctl <action> <systemd_unit>Replace <action> with the action you want to perform to enable or disable the service, for example,
startorstop, and replace <systemd_unit> with the service unit name, for example,httpd.NoteStarting a particular service might require starting one or more other services (positive dependency) or stopping one or more services (negative dependency). In systemd, positive and negative dependencies between services exist.
When you try to start a new service, systemd resolves all dependencies automatically, without explicit notification to the user. This means that if you are already running a service, and you try to start another service with a negative dependency, the first service is automatically stopped.
For example, if you are running the
httpdservice (Apache web server) and then try to start the NGINX service, systemd will automatically stop httpd first. This is because both services are web servers that cannot run simultaneously on the same port (usually port 80 or 443).
2.4. Restarting and reloading a system service
To restart or reload a system service in the current session, use the systemctl command. You can use this command to stop the selected service unit and start it again, restart if service is already running, or reload the service without interrupting its execution.
Prerequisites
- You have administrative privileges.
Procedure
Restart a system service:
# systemctl restart <name>.serviceReplace
<name>with the name of the service unit you want to restart (for example,httpd).Restart a service unit only if the corresponding service is already running:
# systemctl try-restart <name>.serviceReload the configuration without interrupting service execution:
# systemctl reload <name>.serviceCertain services do not support reload operations. If you use
systemctl reload-or-restartorsystemctl reload-or-try-restart, systemd automatically restarts the service if a reload is not possible. Note that a restart of a service might interrupt connections to this service.For details, see
systemctl(1)man page on your system.
2.5. Enabling a system service to start at boot
To enable a service to start automatically at boot, you can use the systemctl command. These changes apply with the next reboot.
Prerequisites
- You have administrative privileges.
Procedure
Check if the unit is masked:
# systemctl status <systemd_unit>If the unit is masked, unmask it first:
# systemctl unmask <systemd_unit>Enable a service to start at boot time:
# systemctl enable --now <systemd_unit>Replace
<systemd_unit>with the name of the service unit you want to enable, for example,httpd.
2.6. Disabling a system service to start at boot
To reduce boot time of your system, you need to either disable or mask the services that start automatically at boot time.
If you disable a service, it will not start at boot, but you can start it manually.
To prevent a service unit from starting automatically or manually, you can mask the service. Masking is a way of disabling a service that makes the service permanently unusable until it is unmasked again.
Prerequisites
- You have administrative privileges.
Procedure
Disable a service to start at boot:
# systemctl disable <name>.serviceReplace
<name>with the name of the service unit you want to disable (for example,bluetooth). Optionally, pass the--nowcommand to also stop the service if it is currently running.To prevent the unit from being accidentally started by an administrator or as a dependency of other units, mask the service:
# systemctl mask <name>.serviceFor details, see the
systemctl(1)man page on your system.
Chapter 3. Booting into a target system state
To set a permanent boot environment or enter a recovery mode, use systemd targets to have full control over your system functionality. The systemd init system is a set of systemd unit types such as systemd.target, multi-user.target, shutdown.target.
3.1. Target unit files
To group various systemd units through a chain of dependencies during boot process of a system, you need to use targets in systemd. Targets in systemd are groups of related units to act as synchronization points during the start of your system.
Target unit files end with the .target file extension. It represents the systemd targets. For example, the multi-user.target unit starts other essential system services such as NetworkManager (NetworkManager.service) or D-Bus (dbus.service) and activates another target unit named basic.target.
You can set the following systemd targets as default or current targets:
| Target | Purpose |
|---|---|
|
| unit target that pulls in the base system and spawns a rescue shell |
|
| unit target for setting up a multi-user system |
|
| unit target for setting up a graphical login screen |
|
| unit target that starts an emergency shell on the main console |
For more information, see systemd.special(7) and systemd.target(5) man pages on your system
3.2. Changing the default target for booting a system
To change the default target, you need to modify the current default.target symbolic link to point to the new target unit. When you set a new default target unit, the current target remains unchanged until the next reboot.
During the boot process, the system initializes the systemd target to which default.target points. Then, systemd resolves this link and boots into the defined target. The selected default target unit is present in the /etc/systemd/system/default.target file. Each target has a certain level of functionality and groups other units. Additionally, target units act as synchronization points during boot. The systemd target types include graphical.target, multi-user target, and so on.
Prerequisites
- You have administrative privileges.
Procedure
Display the current default target unit
systemduses to start the system:# systemctl get-defaultgraphical.targetList the currently loaded targets:
# systemctl list-units --type targetConfigure the system to use a different target unit by default:
# systemctl set-default <name>.targetReplace
<name>with the name of the target unit you want to use by default.# systemctl set-default multi-user.targetRemoved /etc/systemd/system/default.target Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.targetOptional: To immediately switch to the new default target unit:
# systemctl isolate default.target
Verification
Verify the default target unit:
# systemctl get-default multi-user.target- Reboot the system.
3.3. Temporarily changing the current target
To troubleshoot or recover the system, you can temporarily change the current target without rebooting the system. To switch to a different target, use the systemctl isolate command.
By selecting or changing these targets, you define and control selective services and units starting during the boot process. Also, you can view the current default, switch targets, or access the emergency shell prompt as needed
Prerequisites
- You have administrative privileges.
Procedure
Display the list of targets you can select:
$ systemctl list-units --type targetChange to a different target unit in the current session:
# systemctl isolate <name>.targetReplace <name> with the name of the target unit you want to use in the current session.
# systemctl isolate multi-user.targetThis command starts the target unit named
multi-userand all dependent units, and immediately stops all other units that are not part of the new target. As this is a temporary operation, the system will boot again into the default target when you reboot the host. You can only isolate targets that have theAllowIsolate=yesoption set in the unit files.For details, see the
systemctl(1)man page on your system.
3.4. Booting to rescue mode
To troubleshoot or repair the system, you can boot into the rescue mode to enter a single-user environment. This happens when the system fails to reach a later target and the existing booting process fails.
In the rescue mode, apart from not activating network interfaces, the system tries to mount all local file systems and start required system services.
Prerequisites
- You have administrative privileges.
Procedure
Enter the rescue mode:
# systemctl rescueBroadcast message from root@localhost on pts/0 (Fri 2023-03-24 18:23:15 CEST): The system is going down to rescue mode NOW!NoteThis command is similar to
systemctl isolate rescue.target, but it also sends an informative message to all users currently logged in the system.To prevent
systemdfrom sending a message, enter:# systemctl --no-wall rescue
Troubleshooting
If you cannot boot the system in the rescue mode, you need to boot in the emergency mode to enter in a minimal environment. In the emergency mode, the system mounts the root file system only for reading and initiates essential services. Additionally, the system neither mounts any other local filesystems nor activates network interfaces.
3.5. Troubleshooting the boot process
To enter in the most minimal environment for troubleshooting the boot process, you can select a non-default target at boot time. Choose the emergency mode to enter in the most minimal environment. Changing the target at boot time affects only a single boot event.
Prerequisites
- You have administrative privileges.
Procedure
-
Reboot the system, and interrupt the boot loader menu countdown by pressing any key except the
Enterkey to initiate a normal boot. - Select the kernel entry that you want to start.
-
Press the
ekey to edit the current entry. -
Navigate to the end of the line that starts with
linuxand press Ctrl+E to jump to the end of this line. To select a different boot target, append the
systemd.unit=parameter to the end of the line that starts withlinux:linux ... systemd.unit=<name>.targetReplace
<name>with the name of the target unit you want to use. For example,systemd.unit=emergency.target- Press Ctrl+X to boot with these settings.
Chapter 4. Shutting down, suspending, and hibernating the system
To administer and manage data and settings on a system, use the systemd power management options. It includes tasks such as managing power consumption, performing proper system shutdowns to protect your data, and restarting the system to apply changes and updates.
4.1. Scheduling a system shutdown
To perform maintenance tasks and apply updates to applications, you can schedule a delayed shutdown by using the shutdown command. It is important to schedule a shutdown for system maintenance tasks to avoid data loss and unexpected system failures.
Prerequisites
- You have administrative privileges.
Procedure
Shut down the system and power off the machine at a certain time:
# shutdown --poweroff hh:mmWhere
hh:mmis the time in the 24-hour time notation. To prevent new logins, the system creates the/run/nologinfile 5 minutes before the shutdown.When you specify time of the
shutdowncommand, you can notify users logged in to the system of the planned shutdown by specifying an optional wall message. For example:# shutdown --poweroff 13:59 "Attention. The system will shut down at 13:59"Shut down and halt the system after a delay, without powering off the machine:
# shutdown --halt +mWhere
+mis the delay time in minutes. You can use thenowkeyword as an alias for+0.Cancel a pending shutdown:
# shutdown -cFor details, see
shutdown(8)man page on your system.
4.2. Shutting down the system using the systemctl command
To administer and manage data and settings on a system, use the systemd power management options. You can shut down the system and power off the machine or shut down and halt the system without powering off the machine by using the systemctl command.
Prerequisites
- You have administrative privileges.
Procedure
Shut down the system and power off the machine:
# systemctl poweroffUse the
--whenoption with thesystemctl poweroffcommand to specify time:# systemctl poweroff --when="+15min"NoteBy default, running either of these commands causes
systemdto send an informative message to all users that are currently logged into the system.To prevent
systemdfrom sending this message, run the selected command with the--no-wallcommand line option.
4.3. Restarting the system
To apply pending changes and updates, you can restart the system by using the systemctl command. When you restart the system, systemd stops all running programs and services, the system shuts down, and then starts again immediately.
Prerequisites
- You have administrative privileges.
Procedure
Restart the system:
# systemctl rebootNoteBy default, running this command causes
systemdto send an informative message to all users that are currently logged into the system.To prevent
systemdfrom sending this message, run this command with the--no-walloption.
4.4. Optimizing power consumption by suspending and hibernating the system
To save the current system state and reduce power consumption, you can suspend, hibernate, suspend-then-hibernate, or hybrid sleep the system by using the systemctl command.
To suspend the system, run:
# systemctl suspendSuspending saves the system state in RAM and powers off most devices, except the RAM module. When you turn the machine back on, the system restores its state from RAM without rebooting. Restoring from suspend mode is significantly faster than from hibernation because this operation saves the state in RAM, not on disk. However, the suspended system state is vulnerable to power outages.
To hibernate the system, enter:
# systemctl hibernateHibernating saves the system state on the hard disk drive and powers off the machine. When you turn the machine back on, the system restores its state from the saved data without rebooting. Restoring from hibernation is significantly slower than from suspend mode because this operation saves state on disk, not in RAM. However, the machine does not have to keep electrical power to the RAM module.
To hibernate and suspend the system, enter:
# systemctl hybrid-sleepHybrid sleep combines hibernation and suspend. The system saves the current state to disk and enters a low-power state, allowing faster resume. If there is power loss during the sleep operation, the system recovers the state from the saved disk image, similar to hibernation.
To suspend and then hibernate the system, run:
# systemctl suspend-then-hibernateThis mode first suspends the system, saving the state to RAM in low-power mode. If the system remains suspended for a duration you define in
HibernateDelaySec, it then hibernates. Hibernation saves the state to the hard disk and powers off the system completely. This mode conserves battery power while enabling quick resume. It also protects your data during power failures.
4.5. Changing the behavior of the power button when GNOME is not running
To prevent the system from shutting down when you press the power button, you need to modify settings for the non-graphical systemd target. Select the option according to requirement.
Prerequisites
- You have administrative privileges.
Procedure
-
Edit the
/etc/systemd/logind.confconfiguration file to set theHandlePowerKeyvariable. To reboot the system when you press the power button, set the
rebootvalue:HandlePowerKey=rebootUse one of the following options:
-
poweroff: Shut down the computer. -
reboot: Reboot the system. -
halt: Initiate a system halt. -
kexec: Initiate akexecreboot. -
suspend: Suspend the system. -
hibernate: Initiate system hibernation. -
ignore: Do nothing.
-
Restart the
systemd-logindservice to apply the changes:# systemctl reload systemd-logind
4.6. Changing the behavior of the power button in GNOME
To prevent the system from suspending when you press the power button, modify settings for the GNOME login screen and user session. You can select one of the options: physically on a system or virtually from a remote console.
Prerequisites
- You have administrative privileges.
Procedure
Create a local database for system-wide settings in the
/etc/dconf/db/local.d/01-powerfile:[org/gnome/settings-daemon/plugins/power] power-button-action=<value>Replace
<value>with one of the following power button actions:-
nothing: Does nothing. -
suspend: Suspends the system. -
hibernate: Hibernates the system. interactive: Shows a pop-up query asking the user what to do.In the interactive mode, when you press the power button, the system automatically powers off after 60 seconds. You can select a different behavior from the pop-up query.
-
Optional: To override existing settings and prevent other users from changing it, edit configuration in the
/etc/dconf/db/local.d/locks/01-powerfile:/org/gnome/settings-daemon/plugins/power/power-button-actionUpdate the system databases:
# dconf update- Log out and log in again for the system-wide settings to take effect.
Verification
- Press the power button and check if the system performs the action you configured.
Chapter 5. Optimizing systemd to shorten the boot time
You can optimize system performance by managing services associated with systemd. Review services that systemd starts during boot time and evaluate them according to your requirements. Disabling certain services that start at boot can shorten the boot time.
5.1. Examining system boot performance
You can tune the systemd service by using the systemd-analyze command to shorten boot time and examine boot performance.
Procedure
List all enabled services to determine
systemdto tune the boot time:$ systemctl list-unit-files --state=enabledAnalyze the information about the time that the last successful boot took:
$ systemd-analyzeAnalyze the unit initialization time of each
systemdunit:$ systemd-analyze blameThe output lists the units in descending order according to the time they took to initialize during the last successful boot.
Identify critical units that took the longest time to initialize at the last successful boot:
$ systemd-analyze critical-chain
Verification
The output with red color text indicates the units that can critically slow down the boot.
For details, see
systemd(1),systemctl(1), andsystemd-analyze (1)man pages on your system.
5.2. A guide to disable selective services
To reduce boot time of your system, you need to selectively disable only the non-essential services that start automatically at boot time.
List enabled services:
$ systemctl list-unit-files --state=enabledDisable a service:
# systemctl disable <service_name>
Some services are not critical yet required for normal functioning of Red Hat Enterprise Linux (RHEL). Except these services, you can disable other services that are enabled by default with a minimal installation of RHEL.
| Service name | Details |
|---|---|
|
|
Disable |
|
|
Be aware that no items from |
|
|
A symlink to |
|
|
A symlink to |
|
|
A symlink to |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
This service is not started unless the |
|
|
Disable |
|
|
Disable |
|
|
Disable After enabling this service, the system does not finish the boot before the network connection is working. This setting prolongs the boot time significantly. |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
An alias for |
|
|
Disable |
|
|
Disable |
|
|
Disable |
|
|
Disable |
To find details about a service, use one of the following commands:
$ systemctl cat <service_name>$ systemctl help <service_name>
The systemctl cat command displays the contents of a service’s main unit file, typically located at /usr/lib/systemd/system/<service>, along with any override files. Overrides include custom unit files in /etc/systemd/system/<service> or drop-in configuration files in corresponding unit.type.d directories. For details, see the systemd.unit(5) man page or use systemctl help <service> to view the manual for a specific service.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}