Table of Contents
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 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.
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.
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.
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.
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.
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.
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
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 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.
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.
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:
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.
- 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.
- 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, 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
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 ● ├─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 are also the --before and --after flags, which are used to show units starting before or after the specified unit.
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.
Whenever you make edits or remove any of the unit files, you need to make sure that changes are applied by using this command.
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.
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.
To completely shut down the server, you use the poweroff command.
And to reboot the server, you can use the reboot command.
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.
What is the purpose of systemd, and how is it different from other init systems?
What are some common <em>systemctl</em> commands that are used to manage services?
How can I view the status of a service using systemctl?
Can I create my own custom service files using systemd?
What are systemd targets, and how can I use them?
Our Sales and Support teams are available 24 hours by phone or e-mail to assist.