Show Table of Contents
Behavior of
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
| service | systemctl | Description |
|---|---|---|
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
| chkconfig | systemctl | Description |
|---|---|---|
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 NamesBehavior 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.serviceCreated 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
| Field | Description |
|---|---|
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.service10.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.service10.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.service10.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.service10.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.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.