What is Systemctl? An In-Depth Overview

What is Systemctl? 

The systemctl command is a utility which is responsible for examining and controlling the systemd system and service manager. It is a collection of system management libraries, utilities and daemons which function as a successor to the System V init daemon. The new systemctl commands have proven quite useful in managing a servers services. It provides detailed information about specific systemd services, and others that have server-wide utilization.

Keep in mind that most of the systemctl commands will not provide any output if they have been successful. However, if the systemctl command has failed to complete the task, you will get an error message stating that it failed.

Managing Services

What is a Service? 

In the systemd utility, a service is referred to as a unit. A unit is any resource that the system knows how to act on and administrate. A unit is the principal object that the systemd tools know how to address. These assets are defined in a configuration file called a unit file.

Check Service Status

Using systemctl, we can check the status of any systemd service on the managed dedicated server. The status command provides information about a service. It also lists the running state, or detail on why it is not running, or if a service has been stopped unintentionally. If we are connected to the server as a non-root user, we will have to run the systemctl commands using.

systemctl status servicename.service

This unit can be called without the .service extension. Since systemctl will look for those files with .service suffix, the command can also be used like this.

systemctl start servicename

Example of status output:

[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

The systemctl utility can also be used to start or stop systemd services using a service unit file, with or without that .service suffix.

systemctl start servicename.service

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

systemctl stop servicename.service

Keep in mind that the start order can only be used on systemd services that are not currently running, and the stop command used only with running services.

Restarting or Reloading a Service

A running service can be restarted using the restart command to avoid stopping and starting it manually using the following command.

systemctl restart servicename.service

Occasionally, we do not need to restart a service to apply configuration changes, if any were you made. Instead, we can use the reload command to restart the service which implements any changes to the running service.

systemctl reload servicename.serivce

If we are not sure about which of the two commands we should use, there is an additional option using the reload-or-restart command which will automatically determine it for us.

systemctl reload-or-restart servicename.service

Enable or Disable a Service

When it comes to cloud server services, we require most of them to 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. This is where the enable and disable commands come into play. Using the enable command, we can modify how the systemd service responds once the server has been started or rebooted. It will update the service settings, which then tells systemd that the specific service needs to start up automatically, once the server is up. The command to accomplish this is as follows.

systemctl enable servicename.service

While most of the services like HTTPD, MySQL, MariaDB, etc. will have already automatically started, we may need to enable the automatic startup for some of them manually. Similar to how we can set a service to automatically start when the server boots up, we can also disable a service using the following command.

systemctl reload-or-restart servicename.service

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

System State Overview

All the systemctl commands that we have covered are mainly used to manage individual services. Let's review some other commands systemctl has to offer and their uses.

What is a Unit File?

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

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 the example of the output of that command.

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 we have an example of the output, let's 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 the method the unit runs in.
• DESCRIPTION: This short description contains what each unit is and what it does.

Unit States

Using the systemctl list-units command will reveal all the units that are “loaded” and “active” state in the LOAD and ACTIVE columns; however, if we wish to get a more detailed list of all the services, we need to employ the usage of command flag. In this case, the --all flag.

systemctl list-units --all

Using the -all flag, we 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, we can use additional flags to further filter the output of list-units. One of them would be the --state= flag. We can use this flag to further filter the state in the LOAD, ACTIVE, and SUB columns. 

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

Just as we can filter out the units by their state, we 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 had four different states, which are: 

• Enabled
• Disabled
• Static
• Masked

Masked Units

As you can see in the output above, many of the units show a staticSTATE status. This indicates that those units do not have an “install” section within the unit's configuration file, and therefore, cannot be enabled. On the other hand, some units may be masked, and as such, we will not be able to start it. Masked units will provide output using the start command if we attempt to launch it.

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

Unmasking a unit is simple and will return the unit to the state where it can be started or enabled.

systemctl unmask servicename.service

Creating a Unit File

Occasionally, we 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 is accomplished like so.

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

Next, we will open the newly created unit file in a text editor (like vim or nano) and add the service configuration options. Below, we 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 breakdown what these settings mean before we proceed further:

1. Description: The description is the description of the service, and will be displayed when we 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, we will need to tell the system about it with the following commands.

systemctl daemon-reload
systemctl start servicename.service

Viewing a Unit File

Once the unit file has been created, we 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 us. It can be performed with the following command.

systemctl cat servicename.service

Viewing Dependencies

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

systemctl list-dependencies servicename.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 is also the --before and --after flags which are used to show unit starting before or after the specified unit.

View Properties

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

systemctl show servicename.service

This will give you 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 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 us 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 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 we wish to edit using file itself rather than creating a snippet, we 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

We 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 we make edits or remove any of the unit files, we need to make sure that changes are applied by using this command.

systemctl daemon-reload

Using Targets (Runlevels)

What is a Systemd Target?

When it comes to unit files, there are special files that we call targets that describe a system state or synchronization point. These files can be identified by a suffix, which is called .target.

What are these .target files for? They can be used to change the system to certain states, similar to how other init systems use runlevels.

List Targets

There is a number of target files on the server systems, and we 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, we can activate multiple targets at once. In order to see all active targets, we use the following command.

systemctl list-units --type=target

Stopping or Rebooting the Server

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

systemctl halt

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

systemctl poweroff

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

systemctl reboot

Conclusion

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

By providing the above information, we hope 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, we can be reached via phone @800.580.4985, a chat or support ticket to assisting you with this process.