Beginners Guide to Managing Services Using systemd
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 CentOS/RHEL, the ﬁrst 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 speciﬁc ﬁle 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.
[root@host ~]# systemctl list-units --type=service UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running Job spooling tools auditd.service loaded active running Security Auditing Service chronyd.service loaded active running NTP client/server crond. crond.service loaded active running Command Scheduler dbus.service loaded active running D-Bus System Message ...output omitted...
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 conﬁguration 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 ﬁlter by the values in the LOAD, ACTIVE, or SUB ﬁelds.
[root@host ~]# systemctl list-units --type=service --all UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running Job spooling tools auditd.service loaded active running Security Auditing ... auth-rpcgss-module.service loaded inactive dead Kernel Module ... chronyd.service loaded active running NTP client/server cpupower.service loaded inactive dead Configure CPU power ... crond.service loaded active running Command Scheduler dbus.service loaded active running D-Bus System Message Bus ● display-manager.service not-found inactive dead display-manager.service ...output omitted...
The systemctl command without any arguments lists units that are both loaded and active.
[root@host ~]# systemctl UNIT LOAD ACTIVE SUB DESCRIPTION proc-sys-fs-binfmt_misc.automount loaded active waiting Arbitrary... sys-devices-....device loaded active plugged Virtio network... sys-subsystem-net-devices-ens3.device loaded active plugged Virtio network... ... -.mount loaded active mounted Root Mount boot.mount loaded active mounted /boot ... systemd-ask-password-plymouth.path loaded active waiting Forward Password... systemd-ask-password-wall.path loaded active waiting Forward Password... init.scope loaded active running System and Servi... session-1.scope loaded active running Session 1 of... atd.service loaded active running Job spooling tools auditd.service loaded active running Security Auditing... chronyd.service loaded active running NTP client/server crond.service loaded active running Command Scheduler ...output omitted...
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 ﬁles installed, use the systemctl list-unit-files command. For example:
[root@host ~]# systemctl list-unit-files --type=service UNIT FILE STATE arp-ethers.service disabled atd.service enabled auditd.service enabled auth-rpcgss-module.service static [email protected] enabled blk-availability.service disabled ...output omitted...
In the output of the systemctl list-units-files command, valid entries for the STATE ﬁeld are enabled, disabled, static, and masked.
Viewing Service States
View the status of a speciﬁc 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.
[root@host ~]# systemctl status sshd.service ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-02-14 12:07:45 IST; 7h ago Main PID: 1073 (sshd) CGroup: /system.slice/sshd.service └─1073 /usr/sbin/sshd -D ... Feb 14 11:51:39 host.example.com systemd: Started OpenSSH server daemon. Feb 14 11:51:39 host.example.com sshd: Could not load host key: /et...y Feb 14 11:51:39 host.example.com sshd: Server listening on 0.0.0.0 .... Feb 14 11:51:39 host.example.com sshd: Server listening on :: port 22. Feb 14 11:53:21 host.example.com sshd: error: Could not load host k...y Feb 14 11:53:22 host.example.com sshd: Accepted password for root f...2 ...output omitted...
This command displays the current status of the service. The meaning of the ﬁelds are:
|Loaded||Whether the service unit is loaded into memory.|
|Active||Whether the service unit is running and if so, how long it has been running.|
|Main PID||The main process ID of the service, including the command name.|
|Status||Additional information about the service.|
Several keywords indicating the state of the service can be found in the status output:
|loaded||Unit configuration file has been processed.|
|active (running)||Running with one or more continuing processes.|
|active (exited)||Successfully completed a one-time configuration.|
|active (waiting)||Running but waiting for an event.|
|enabled||Is started at boot time.|
|disabled||Is not set to be started at boot time.|
|static||Cannot be enabled, but may be started by an enabled unit automatically.|
Verifying the Status of a Service
The systemctl command provides methods for verifying the speciﬁc states of a service. For example, use the following command to verify that the a service unit is currently active (running):
[root@host ~]# systemctl is-active sshd.service active
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:
[root@host ~]# systemctl is-enabled sshd.service enabled
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:
[root@host ~]# systemctl is-failed sshd.service active
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 command:
# systemctl --failed --type=service