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.
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
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.
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.
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.
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:
As you can see in the output above, many of the units show a static STATE 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:
- Description: The description is the description of the service, and will be displayed when we use the systemctl status command for the created service.
- After: The After setting indicates that a service will only start on reboot after a specified target or another service has been started.
- ExecStart: The ExecStart is the path to the actual executable file of the service.
- 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
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 ● ├─firstname.lastname@example.org ● ├─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.
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.
Whenever we make edits or remove any of the unit files, we need to make sure that changes are applied by using this command.
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.
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.
To completely shut down the server, we use poweroff command.
And to reboot the server, we can use the reboot command.
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.