What is Systemctl? An In-Depth Overview

Table of Contents

1. What is Systemctl?
2. Managing Services
3. System State Overview
4. What is a Unit File?
5. Working with Unit Files
6. Using Targets (Runlevels)
7. Stopping or Rebooting the Server
8. Conclusion
9. FAQ

What is Systemctl?

Systemctl is a command-line tool that allows for the management and monitoring of the systemd system and service manager. It consists of a range of system management utilities, libraries, and daemons that have replaced the previous System V (SysV) init daemon. With its various commands, systemctl proves to be a helpful tool in managing a server's services. It provides detailed information about individual systemd services as well as those that have system-wide usage.

Managing Services

Managing services is an important aspect of maintaining a Linux system, as it allows users to control what programs are running and ensure that they are functioning correctly.

What is a Service?

A service, also known as a unit in the systemd utility, refers to any resource that the operating system can recognize and manage. This resource can be a software application, a device, or any other entity that the system can act on. In systemd, the unit is the fundamental object that the system tools use to manage and interact with these resources. Unit files are configuration files that define the attributes and behavior of each unit, such as how it should start, stop, and restart. 

The systemd tools use this information to ensure that the units are running correctly and that their dependencies are met. Overall, services/units are critical components of a Linux system that ensure its functionality and stability.

Check Service Status

Systemctl provides a means to check the status of any systemd service running on dedicated server hosting. By issuing the status command, you can gather information about a particular service, including its current state and details on why it may not be running, such as unintentional stopping. However, if you are logged into the server as a non-root user, you need to run the systemctl commands with elevated privileges.

systemctl status service_name.service

It is possible to refer to a unit without specifying the .service extension. This allows you to call the unit by name, and since systemctl searches for unit files with a .service suffix, it can locate and operate on the desired unit even without the extension. As such, the command can be executed without explicitly adding the .service extension to the unit name.

systemctl status service_name

Here is an example of what a status command output looks like for the httpd service.

[root@host ~]# systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2020-05-08 14:15:54 EDT; 1 weeks 2 days ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 3767 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
 Main PID: 1321 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec"
   CGroup: /system.slice/httpd.service
           ├─1321 /usr/sbin/httpd -DFOREGROUND
           ├─3769 /usr/sbin/httpd -DFOREGROUND

Starting or Stopping a Service

We can utilize the systemctl utility to initiate or halt systemd services through a service unit file, which can be specified with or without the .service extension.

systemctl start service_name.service

The same rules apply when you want to stop a specific service.

systemctl stop service_name.service

It is essential to note that the start order can only be executed on systemd services that are currently inactive, while the stop command can be used only on services that are actively running.

Restarting or Reloading a Service

To avoid manually stopping and starting a running service, you can use the restart command to initiate a service restart. This command allows you to restart a service without the need to issue separate stop and start commands. Instead, the restart command gracefully stops and then starts the service again, ensuring that any changes made to the configuration file are applied.

systemctl restart service_name.service

In some cases, it may not be necessary to perform a complete service restart to apply any configuration changes made. Instead, you can use the reload command to initiate a service reload, which allows the service to re-read its configuration files and implement any changes without the need to restart.

systemctl reload service_name.service

If you are unsure whether to use the reload or restart command for a particular service, you can use the reload-or-restart command, which automatically determines the appropriate action to take.

systemctl reload-or-restart service_name.service

Enable or Disable a Service

When it comes to cloud server services, it is required that most of them be online and active all the time. Starting them manually is not a convenient method to employ due to the number of services required to run on a server. To address this issue, you can use the enable and disable commands to manage the behavior of systemd services when the server is started or rebooted.

By using the enable command, you can update the service settings to ensure that systemd starts the specific service automatically once the server is up. This command modifies the service configuration to tell systemd that the service needs to start up automatically on boot.

systemctl enable service_name.service

Although many services, such as HTTPD, MySQL, MariaDB, etc., start automatically, you may need to manually enable automatic startup for some services. Similarly, you can also disable a service from starting automatically using the following command. This is useful when you do not need a particular service to start automatically on boot or when troubleshooting issues with the service.

systemctl disable service_name.service

The disable command prevents the automatic startup of a service at boot time, leaving it inactive until it is started manually.

System State Overview

The systemctl command offers a wide range of functions that go beyond just managing individual services. Here are some additional systemctl commands and their uses.

List All Units Currently Running

This command lists all active units currently running on the system, including services, timers, sockets, and more.

systemctl list-units

Display List of Dependent Units

This command displays a list of units that are dependent on a specific unit. It shows a hierarchical view of units that must be started or stopped in a particular order.

systemctl list-dependencies

List All Currently Active Systemd Jobs

This command displays a list of all currently active systemd jobs. Jobs are used to track the progress of any systemd operation, such as starting or stopping a service.

systemctl list-jobs

Reload Systemd Manager Configuration Files

This command reloads the systemd manager configuration files. Use this command after modifying any service files or after adding new units to the system.

systemctl daemon-reload

Check if a Particular Service is Running

This command checks if a particular service is currently running or not. It returns an active or inactive status based on the current state of the service.

systemctl is-active

Check if a Particular Service is Set to Auto Start

This command checks if a particular service is set to automatically start on boot. It returns an enabled or disabled status based on the current configuration of the service.

systemctl is-enabled

By using these commands, you can get a more in-depth view of the system and the services running on it, as well as modify their behavior to better suit your needs.

What is a Unit File?

A unit file is a flat-text file that contains essential information about a specific unit, which can be a service, socket, device, mount point, swap file, partition, start-up target, asset management slice, or even a group of externally created processes. 

Essentially, it is a configuration file that describes the properties of the unit, including how it should be started, stopped, and managed by the systemd system and service manager. 

A unit file usually contains several sections, each with a unique purpose, such as defining dependencies, specifying commands to execute, setting resource limits, and configuring logging. Systemd uses these unit files to control and manage the various units in the system, providing a simple and effective way to organize and manage system resources.

Working with Unit Files

List Units

The list-units command displays all the active systemd services on your server. Our output is similar to the information provided by the systemctl status command but not as detailed.

systemctl list-units

Here is an example of the output that this command gives.

root@host [~]# systemctl list-units
UNIT 		        LOAD   ACTIVE SUB DESCRIPTION
crond.service 	  loaded active running Command Scheduler
dovecot.service     loaded active running Dovecot IMAP/POP3 email server
firewalld.service   loaded active running firewalld - dynamic firewall daemon
httpd.service 	  loaded active running The Apache HTTP Server
mariadb.service     loaded active running MariaDB database server
named.service 	  loaded active running Berkeley Internet Name Domain (DNS)

Now that you have an example of the output, see below to review the meaning of each column.

• UNIT: The name of the systemd unit.
• LOAD: This indicates if the unit's configuration is being loaded by systemd. If it is, the configuration is stored in the server's memory.
• ACTIVE: This states the status of the unit and shows whether it is active or not.
• SUB: This provides more detailed information about the unit, which will vary depending on the type of unit, state, and method the unit runs in.
• DESCRIPTION: This short description contains what each unit is and what it does.

Unit States

To get a more comprehensive list of all services and their statuses, the --all flag can be used with the systemctl list-units command. While the LOAD and ACTIVE columns show the loaded and active states of units, respectively, the --all flag provides more detailed information.

systemctl list-units --all

Using the --all flag, you can obtain a list of all the systemd units that are loaded or that systemd has tried to load. This output will also show the services that are currently in an inactive, dead, failed state, or that have not been found on the disk of the server.

While this flag provides the full output of all the units on the server, which systemd loaded into memory, you can use additional flags to further filter the output of list-units. One of them would be the --state= flag. You can use this flag to further filter the state in the LOAD, ACTIVE, and SUB columns.

systemctl list-units --all --state=failed

Just as you can filter out the units by their state, you can also use the same type to accomplish the same task.

systemctl list-units --all --type=mount

The list-units command displays the units that systemd has loaded or attempted to load into memory. But what about the units that are not in the systemd memory? This is where the list-unit-files flag comes into play, as this command will display all available units on the server.

systemctl list-unit-files

The output will be given in two columns with the name of a file and state.

UNIT FILE 		                 STATE
Proc-sys-fs-binfmt_misc.automount  static
dev-hugepages.mount 	           static
dev-mqueue.mount 	                 static
proc-sys-fs-binfmt_misc.mount      static
sys-fs-fuse-connections.mount      static
sys-kernel-config.mount 	     static
sys-kernel-debug.mount 	           static
tmp.mount 		                 disabled

The STATE column has four different states, which are: 

• Enabled
• Disabled
• Static
• Masked

Masked Units

The output of the list-unit-files command shows that some units have a static STATE status, indicating that they lack an install section in their configuration file; therefore, they cannot be enabled. However, it's worth noting that some units may also be masked, which means they have been explicitly disabled and cannot be started. Attempting to launch a masked unit using the start command will generate an error message.

systemctl start service_name.service
Failed to start service_name.service: Unit is masked.

To unmask a unit and enable it, you can use the unmask command followed by the name of the unit.

systemctl unmask service_name.service

Creating a Unit File

Occasionally, you may need to create a unit file for a custom daemon or another instance of an already existing service. The creation of a unit file is executed via the root user in the /etc/systemd/system/ directory. This can be accomplished like this with the below.

touch /etc/systemd/system/service_name.service
chmod 644 /etc/systemd/system/service_name.service

Next, you will open the newly created unit file in a text editor, such as vim or nano, and add the service configuration options. Below, you can see a basic example of the unit file.

[Unit]
Description=This is the manually created service
After=network.target

[Service]
ExecStart=/path/to/executable

[Install]
WantedBy=multi-user.target

Let’s quickly break down what these settings mean before you proceed further.

1. Description: The Description is the description of the service, and it will be displayed when you use the systemctl status command for the created service.
2. After: The After setting indicates that a service will only start on reboot after a specified target or another service has been started.
3. ExecStart: The ExecStart is the path to the actual executable file of the service.
4. WantedBy: The WantedBy setting states the target that the service should start under. This is similar to runlevels.

Once the service file has been created, you will need to tell the system about it with the following commands.

systemctl daemon-reload
systemctl start service_name.service

Viewing a Unit File

Once the unit file has been created, you do not necessarily need to navigate to the file itself to see what is written inside. The systemctl command has a feature that displays the content of the unit file for you. It can be performed with the following command.

systemctl cat service_name.service

Viewing Dependencies

Just like you can see inside a unit file, you can also use the following command to display the dependency tree of that unit.

systemctl list-dependencies service_name.service

[root@host ~]#  systemctl list-dependencies httpd.service
httpd.service
● ├─-.mount
● ├─system.slice
● └─basic.target
● ├─microcode.service
● ├─rhel-dmesg.service
● ├─selinux-policy-migrate-local-changes@targeted.service
● ├─paths.target
● ├─slices.target
● │ ├─-.slice
● │ └─system.slice
...

There are a few useful flags that can be added to the command, such as the --all flag, which lists all dependencies recursively, or --reverse, which will list them in reverse order. There are also the --before and --after flags, which are used to show units starting before or after the specified unit.

View Properties

Additionally, you can see the properties of a unit by using the show command.

systemctl show service_name.service

This will give you an output similar to the one below.

[root@host ~]#  systemctl show httpd.service
Type=notify
Restart=no
NotifyAccess=main
RestartUSec=100ms
TimeoutStartUSec=1min 30s
TimeoutStopUSec=1min 30s
WatchdogUSec=0
WatchdogTimestamp=Thu 2020-06-25 05:43:53 EDT

In case you are looking for a single setting, you can use -p flag with the setting name. For example, to get the process ID (PID) of a running service, use this command.

[root@host ~]#  systemctl show httpd.service -p MainPID
MainPID=4004

Edit Unit Files

In cases where the unit files need to be modified, systemctl has a built-in editing system that allows you to modify unit files without searching for them on the server. This can be done using the edit command.

systemctl edit httpd.service

This creates a directory in /etc/systemd/system named the same as the service with a .d appended to it. It looks like this: /etc/systemd/system/httpd.service.d.

This is where the edits would be stored, and any directives within this file would override the main unit file. The snippet created in that directory would be named override.conf. In case you wish to edit using the file itself rather than creating a snippet, you can use the following command.

systemctl edit --full httpd.service

Removing Unit Files

Removing a unit file and overriding snippets can be accomplished using the following commands.

rm -r /etc/systemd/system/httpd.service.d

You can use the command below to remove the snippet directory, which overrides directives and removes the full modified unit file.

rm /etc/systemd/system/httpd.service

Whenever you make edits or remove any of the unit files, you need to make sure that changes are applied by using this command.

systemctl daemon-reload

Using Targets (Runlevels)

What is a Systemd Target?

A target is a special type of unit file used in systemd that defines a system state or synchronization point. These files can be identified by their suffix, which is always .target.

Targets are used to manage the state of the system and are similar to runlevels used in other init systems. Each target represents a specific state that the system can be in, such as multi-user.target, graphical.target, or rescue.target.

The multi-user.target is the default target in most Linux distributions, which is equivalent to runlevel 3. It is the state in which the system boots to a console interface without any graphical user interface (GUI) elements. In contrast, the graphical.target is equivalent to runlevel 5 and boots the system to a graphical user interface.

By default, systemd has a set of predefined targets, but users can create their own custom targets as needed. With the use of targets, you can easily switch between different system states, making it convenient for administrators to manage the system's behavior.

List Targets

There are a number of target files on the server systems, and you can list them using the following command.

systemctl list-unit-files --type=target

While working with runlevels, activating the runlevels is done one at a time, but when it comes to targets, you can activate multiple targets at once. In order to see all active targets, you use the following command.

systemctl list-units --type=target

Stopping or Rebooting the Server

Finally, you can use systemctl to stop the server, power it off, or to reboot it. For stopping the server, you use the following halt command.

systemctl halt

To completely shut down the server, you use the poweroff command.

systemctl poweroff

And to reboot the server, you can use the reboot command.

systemctl reboot

Conclusion

The systemctl utility is a flexible, versatile, and easy-to-use tool by which you can oversee and interact with the systemd system to create, modify, or remove unit files via the service manager.

The hope of providing the above information is that you have an improved understanding of how systemctl interacts with the init system and a better grasp of the overall task management of the server.

Our Support Teams are full of experienced and talented Linux technicians and system administrators who have an intimate knowledge of multiple web hosting technologies — especially those discussed in this article.

If you are a fully-managed VPS server, Cloud Dedicated, VMWare Private Cloud, Private Parent server, or a Dedicated Server owner, and you are uncomfortable with performing any of the steps outlined, contact Liquid Web support that is available 24/7/365.

FAQ