Last updated:

This article looks at managing services on Linux servers. I will focus on the command line, and on the systemctl utility in particular.

Before diving in, it is worth mentioning that you can perform most tasks via WHM. For instance, the Restart Services interface lets you restart services such as Apache and MySQL/MariaDB. Also, on cPanel servers you can manage services via various restartsrv scripts.

systemd / systemctl

The way services are managed on RHEL-based Linux distributions such as AlmaLinux, Centos and CloudLinux has changed significantly in recent years. Traditionally, nearly all Linux operating systems used the SysVinit daemon for system initialisation and managing services. The main contenders to replace SysVInit were Upstart and systemd. Upstart was adopted in RHEL 6 but since RHEL 7 systemd has become the standard.

Checking the init system

Determining your system’s initialisation daemon can be a little tricky. If you are not sure what init system your server uses then you can start by inspecting PID 1 (as the init system is always the first process):

# ps -p 1
  PID TTY          TIME CMD
    1 ?        02:03:50 systemd

Here, PID 1 is systemd. Unfortunately, SysVinit and Upstart both identify themselves as init. To find out if you are running Upstart you can use the strings utility to inspect the init binary. The below command was run on a Centos 6 server running Upstart:

# strings /sbin/init | grep ^UPSTART

As SysVinit and Upstart belong to the RHEL 5 and 6 era I won’t cover them in this article.

Listing services

You can list all services managed by systemd using the command systemctl list-units:

# systemctl list-units --type=service | head -3
  atd.service                loaded active running   Job spooling tools
  auditd.service             loaded active running   Security Auditing Service
  avahi-daemon.service       loaded active running   Avahi mDNS/DNS-SD Stack

The list will be very long, which is why I limited the output to just the first three lines. What we want to focus on here is what the list tells us. The output shows five columms:

  • Unit is the systemd unit name, such as atd.service.
  • Loaded shows whether or not the configuration file for the service has been loaded.
  • Active shows the high-level activation state. Common values are active, inactive and failed.
  • Sub shows the low-level activation state. Common values are running, failed and exited.
  • Description is a short description of the services.

You can list services with a “failed” status using the --state=failed option:

# systemctl list-units --type=service --state=failed
  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION
● cpanel_php_fpm.service     loaded failed failed FPM service for cPanel Daemons
● cphulkd.service            loaded failed failed cPanel brute force detector services

Often, a “failed” status simply indicates that a service hasn’t been enabled on the server. If you are not using PHP-FPM then you don’t need to enable the service. So, the “failed” status doesn’t always mean there is an issue.

You can quickly check if a service is enabled using the is-enabled command:

# systemctl is-enabled cpanel_php_fpm.service

Listing service units is also useful if you are not sure about the name of a service. For instance, to remind yourself of the name of the FTP service you can pipe the output to grep:

# systemctl list-units --type=service | grep ftp
  pure-ftpd.service          loaded failed failed Pure-FTPd

Enabling and disabling services

Services that should be started during the boot process need to be enabled. If, say, you have installed Docker then you can enable the Docker daemon as follows:

# systemctl enable docker.service

And to disable the Docker service you can use:

# systemctl disable docker.service

Starting and stopping services

Starting and stopping a service is equally straight forward:

# systemctl start docker.service
# systemctl stop docker.service

Reloading and restarting services

If you have changed a configuration file, such as Apache’s httpd.conf file, then you need to reload the file. You can do that with the reload command:

# systemctl reload httpd.service

Not all services can reload their configuration file without a restart. To make sure that the changes are applied you can instead use the reload-or-restart command. This will reload the configuration if possible, or otherwise restart the service.

# systemctl reload-or-restart httpd.service

And as you probably guessed, you can also simply restart a service:

# systemctl restart httpd.service

Checking the status of a service

The status command prints runtime information, including whether or not the service is active and what the main process ID is. The output also includes the most recent log file data.

# systemctl status exim
● exim.service - Exim is a Mail Transport Agent, which is the program that moves mail from one machine to another.
   Loaded: loaded (/etc/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2021-04-11 00:42:11 BST; 2 weeks 0 days ago
 Main PID: 13499 (exim)

More information

There is a lot more to systemd. In particular, I haven’t talked about unit files and systemd targets. If you want to learn more about systemd, the official documentation is available at

cPanel scripts

Although you can use systemctl on cPanel servers it is recommended to use cPanel’s restartsrv scripts. The scripts were introduced when RHEL made the switch from Upstart to systemd, and the scripts work correctly regardless of the init system used. The scripts also make sure that WHM knows about the state of services.

You can see the scripts that are available by listing the contents of the /scripts directory:

# ls -1 /scripts/restartsrv* | head -3

The scripts can do more than just restart services. The following options are available:

  • --check or --status – Check if the service is up and running.
  • --restart – Restart the service.
  • --start – Start the service.
  • --stop – Stop the service.
  • --reload – Reload the configuration file.

You can learn more about the scripts and the available options via the cPanel documentation.