10.2. Managing System Services

Note

To expand your expertise, you might also be interested in the Red Hat System Administration II (RH134) training course.
Previous versions of Red Hat Enterprise Linux, which were distributed with SysV init or Upstart, used init scripts located in the /etc/rc.d/init.d/ directory. These init scripts were typically written in Bash, and allowed the system administrator to control the state of services and daemons in their system. In Red Hat Enterprise Linux 7, these init scripts have been replaced with service units.
Service units end with the .service file extension and serve a similar purpose as init scripts. To view, start, stop, restart, enable, or disable system services, use the systemctl command as described in Table 10.3, “Comparison of the service Utility with systemctl ”, Table 10.4, “Comparison of the chkconfig Utility with systemctl”, and further in this section. The service and chkconfig commands are still available in the system and work as expected, but are only included for compatibility reasons and should be avoided.

Table 10.3. Comparison of the service Utility with systemctl

servicesystemctlDescription
service name start
systemctl start name.service
Starts a service.
service name stop
systemctl stop name.service
Stops a service.
service name restart
systemctl restart name.service
Restarts a service.
service name condrestart
systemctl try-restart name.service
Restarts a service only if it is running.
service name reload
systemctl reload name.service
Reloads configuration.
service name status
systemctl status name.service
systemctl is-active name.service
Checks if a service is running.
service --status-all
systemctl list-units --type service --all
Displays the status of all services.

Table 10.4. Comparison of the chkconfig Utility with systemctl

chkconfigsystemctlDescription
chkconfig name on
systemctl enable name.service
Enables a service.
chkconfig name off
systemctl disable name.service
Disables a service.
chkconfig --list name
systemctl status name.service
systemctl is-enabled name.service
Checks if a service is enabled.
chkconfig --list
systemctl list-unit-files --type service
Lists all services and checks if they are enabled.
chkconfig --list
systemctl list-dependencies --after
Lists services that are ordered to start before the specified unit.
chkconfig --list
systemctl list-dependencies --before
Lists services that are ordered to start after the specified unit.

Specifying Service Units

For clarity, all command examples in the rest of this section use full unit names with the .service file extension, for example: 
~]# systemctl stop nfs-server.service
However, the file extension can be omitted, in which case the systemctl utility assumes the argument is a service unit. The following command is equivalent to the one above: 
~]# systemctl stop nfs-server
Additionally, some units have alias names. Those names can have shorter names than units, which can be used instead of the actual unit names. To find all aliases that can be used for a particular unit, use: 
~]# systemctl show nfs-server.service -p Names

Behavior of systemctl in a chroot Environment

If you change the root directory using the chroot command, most systemctl commands refuse to perform any action. The reason for this is that the systemd process and the user that used the chroot command do not have the same view of the filesystem. This happens, for example, when systemctl is invoked from a kickstart file.
The exception to this are unit file commands such as the systemctl enable and systemctl disable commands. These commands do not need a running system and do not affect running processes, but they do affect unit files. Therefore, you can run these commands even in chroot environment. For example, to enable the httpd service on a system under the /srv/website1/ directory: 
~]# chroot /srv/website1
~]# systemctl enable httpd.service
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.

10.2.1. Listing Services

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 Section 10.2.2, “Displaying Service Status”.

Example 10.1. Listing Services

To list all currently loaded service units, run the following command: 
~]$ 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'
To list all installed service unit files to determine if they are enabled, type: 
~]$ 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.

10.2.2. Displaying Service Status

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 10.5, “Available Service Unit Information”, and if it is executed by the root user, also the most recent log entries.

Table 10.5. Available Service Unit Information

FieldDescription
Loaded Information whether the service unit has been loaded, the absolute path to the unit file, and a note whether the unit is enabled.
Active Information whether the service unit is running followed by a time stamp.
Main PID The PID of the corresponding system service followed by its name.
Status Additional information about the corresponding system service.
Process Additional information about related processes.
CGroup Additional information about related Control Groups (cgroups).
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 Section 10.2.1, “Listing Services”.

Example 10.2. Displaying Service Status

The service unit for the GNOME Display Manager is named gdm.service. To determine the current status of this service unit, type the following at a shell prompt: 
~]# 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.

Example 10.3. Displaying Services Ordered to Start Before a Service

To determine what services are ordered to start before the specified service, type the following at a shell prompt: 
~]# 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]

Example 10.4. Displaying Services Ordered to Start After a Service

To determine what services are ordered to start after the specified service, type the following at a shell prompt: 
~]# 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

10.2.3. Starting a 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 Section 10.2.6, “Enabling a Service”. For information on how to determine the status of a certain service unit, see Section 10.2.2, “Displaying Service Status”.

Example 10.5. Starting a Service

The service unit for the Apache HTTP Server is named httpd.service. To activate this service unit and start the httpd daemon in the current session, run the following command as root: 
~]# systemctl start httpd.service

10.2.4. Stopping a 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 Section 10.2.7, “Disabling a Service”. For information on how to determine the status of a certain service unit, see Section 10.2.2, “Displaying Service Status”.

Example 10.6. Stopping a Service

The service unit for the bluetoothd daemon is named bluetooth.service. To deactivate this service unit and stop the bluetoothd daemon in the current session, run the following command as root: 
~]# systemctl stop bluetooth.service

10.2.5. Restarting a 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 Section 10.2.2, “Displaying Service Status”.

Example 10.7. Restarting a Service

In order to prevent users from encountering unnecessary error messages or partially rendered web pages, the Apache HTTP Server allows you to edit and reload its configuration without the need to restart it and interrupt actively processed requests. To do so, type the following at a shell prompt as root: 
~]# systemctl reload httpd.service

10.2.6. Enabling a 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 Section 10.2.2, “Displaying Service Status”. For information on how to start a service in the current session, see Section 10.2.3, “Starting a Service”.

Example 10.8. Enabling a Service

To configure the Apache HTTP Server to start automatically at boot time, run the following command as root: 
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

10.2.7. Disabling a 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 Section 10.2.2, “Displaying Service Status”. For information on how to stop a service in the current session, see Section 10.2.4, “Stopping a Service”.

Example 10.9. Disabling a Service

Example 10.6, “Stopping a Service” illustrates how to stop the bluetooth.service unit in the current session. To prevent this service unit from starting at boot time, type the following at a shell prompt as root: 
~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

10.2.8. Starting a Conflicting 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.