Controlling Services and Daemons

Introduction to systemd
The systemd daemon manages startup for Linux, including service startup and service management in general. It activates system resources, server daemons, and other processes both at boot time and on a running system.
Daemons are processes that either wait or run in the background, performing various tasks. Generally, daemons start automatically at boot time and continue to run until shutdown or until they are manually stopped. It is a convention for names of many daemon programs to end in the letter d.
A service in the systemd sense often refers to one or more daemons, but starting or stopping a service may instead make a one-time change to the state of the system, which does not involve leaving a daemon process running afterward (called oneshot).
In Red Hat Enterprise Linux, the first process that starts (PID 1) is systemd. A few of the features provided by systemd include:

• Parallelization capabilities (starting multiple services simultaneously), which increase the boot speed of a system.
• On-demand starting of daemons without requiring a separate service.
• Automatic service dependency management, which can prevent long timeouts. For example, a network-dependent service will not attempt to start up until the network is available.
• A method of tracking related processes together by using Linux control groups.

Describing Service Units
systemd uses units to manage different types of objects. Some common unit types are listed below:

• Service units have a .service extension and represent system services. This type of unit is used to start frequently accessed daemons, such as a web server.
• Socket units have a .socket extension and represent inter-process communication (IPC) sockets that systemd should monitor. If a client connects to the socket, systemd will start a daemon and pass the connection to it. Socket units are used to delay the start of a service at boot time and to start less frequently used services on demand.
• Path units have a .path extension and are used to delay the activation of a service until a specific file system change occurs. This is commonly used for services which use spool directories such as a printing system.
• The systemctl command is used to manage units. For example, display available unit types with the systemctl -t help command.

Listing Service Units
You use the systemctl command to explore the current state of the system. For example, the following command lists all currently loaded service units, paginating the output using less.

The above output limits the type of unit listed to service units with the --type=service option. The output has the following columns:
Columns in the systemctl list-units Command Output
**
**UNIT
The service unit name.
LOAD
Whether systemd properly parsed the unit's configuration and loaded the unit into memory.
ACTIVE
The high-level activation state of the unit. This information indicates whether the unit has started successfully or not.
SUB
The low-level activation state of the unit. This information indicates more detailed information about the unit. The information varies based on unit type, state, and how the unit is executed.
DESCRIPTION
The short description of the unit.

By default, the systemctl list-units --type=service command lists only the service units with active activation states. The --all option lists all service units regardless of the activation states. Use the --state= option to filter by the values in the LOAD, ACTIVE, or SUB fields.

The systemctl command without any arguments lists units that are both loaded and active.

The systemctl list-units command displays units that the systemd service attempts to parse and load into memory; it does not display installed, but not enabled, services. To see the state of all unit files installed, use the systemctl list-unit-files command. For example:

In the output of the systemctl list-units-files command, valid entries for the STATE field are enabled, disabled, static, and masked.

Viewing Service States
View the status of a specific unit with systemctl status name.type. If the unit type is not provided, systemctl will show the status of a service unit, if one exists.

This command displays the current status of the service. The meaning of the fields are:

Table 9.1. Service Unit Information

Several keywords indicating the state of the service can be found in the status output:
*Table 9.2. Service States in the Output of systemctl
*

Verifying the Status of a Service
The systemctl command provides methods for verifying the specific states of a service. For example, use the following command to verify that the a service unit is currently active (running):

The command returns state of the service unit, which is usually active or inactive.

Run the following command to verify whether a service unit is enabled to start automatically during system boot:

The command returns whether the service unit is enabled to start at boot time, which is usually enabled or disabled.

To verify whether the unit failed during startup, run the following command:

The command either returns active if it is properly running or failed if an error has occurred during startup. In case the unit was stopped, it returns unknown or inactive.

To list all the failed units, run the systemctl --failed --type=service command.

References
systemd(1), systemd.unit(5), systemd.service(5), systemd.socket(5), and systemctl(1) man pages