This tutorial walks you through the basics of service management in Linux and how to use Systemctl to manage services, get information about system units, and get helpful information about the state of the services in your system.
What is Systemctl?
Systemctl is a Linux command-line utility used to control and manage systemd and services. You can think of Systemctl as a control interface for Systemd init service, allowing you to communicate with systemd and perform operations.
Systemctl is a successor of Init.d system; it contains libraries, daemons, and utilities you can use to manage services in the Linux system.
What is a Service/Unit?
In systemd language, a service or a unit is a resource or an object systemd is aware of and knows how to address.
Although it is technically correct to classify a unit as a service, in systemd, units tend to be more abstract and often comprised of resource pools, filesystem mounts, network protocols, devices, and native Linux services.
Units are defined in a file known as a Unit file. Systemd can manage unit files from any location, but their main location is /etc/systemd/system directory. Unit files in this directory are mainly user-provided. Compared to other locations, the systemd manager will assign higher precedence to unit files within the above directory.
NOTE: You may also find unit files located in the /lib/systemd/system directory, which contains unit files supplied by the system and installed packages. Ensure to check both locations when editing a unit file.
Systemd Unit types
Unit files are labeled with a suffix in the unit file, that give the administrator an indication of its purpose based on the suffix.
The following are the unit files found in systemd.
- .service – Service unit files define how systemd manages a service. They typically end in .service extension. Service unit files describe how to start, stop, reload and restart a service and the dependencies required to manage the service.
- .target – Target units provide synchronization points to other services during startup.
- .slice – slice unit files encode information about systemd slice units. Slice units are part of the Linux control group tree that allows resource allocation and restriction to processes associated with a slice. You can learn more about systemd resource control here.
- .socket – A socket unit file encodes information about network socket, IPC, or a file system FIFO buffer controlled and managed for systemd, which systemd uses for socket-based activation.
- .device – Device unit configurations define a device unit as exposed in the sysfs/udev device tree.
- .timer – Timer units define a timer managed and controlled by systemd for scheduled activation.
- .snapshot – Snapshot unit files allow rollback of the current state of the system after making changes. We create them using the systemd snapshot command.
- .swap – Swap units encode information about swap space, such as the device name or path of the swap space.
- .mount – mount unit files encode information about mount points in the system managed by systemd.
- .automount – these are unit files that define mount points that are automatically mounted.
Those are some of the unit files managed by systemd. Typically, these unit files in a system work closely together to manage the system, services, daemons, and other resources in the system.
NOTE: There are other unit files, but you will not need to worry much about them, unless you are diving deep into the Kernel.
List Unit Files
To view the unit files available in the system, you can list the files in /lib/systemd/system or /etc/systemd/system.
Luckily, systemd has a command for that. We can execute the command:
Running this command will show the units available in the system.
To filter only specific unit files, you can use the –type=[unit-type] option. For example, to show service units files, we use the command:
Here is an example output:
The output from the systemctl list-units command uses a column-based organizational method.
Here is what each column represents.
- UNIT – The first column is the ‘UNIT.’ This shows the name of the unit file.
- LOAD – This shows whether the unit definition loaded correctly.
- ACTIVE – This shows the high-level activation state.
- SUB – This shows the low-level activation state. The values in this column will depend on unit type.
- DESCRIPTION – The unit file’s description.
You can also filter the units by their states. For example, to show only inactive units, use the command:
The above shows inactive (or dead SUB) units. Most units in this state are started before the user sessions; they include Plymouth, network activations service, rescue mode, manual db, and many more.
To show all the unit files in the system, you can append –all option to the list-units command.
You can scroll the list of available units by pressing the space key.
How to View Unit File Contents
To view the entries and configuration in a unit file, you can tell systemd to call the cat command and unit’s name.
For example, to show the contents of the Plymouth unit, use the command
This command will dump the contents of the file as shown below:
How to Edit Unit files
To edit unit files, you can use the systemd command followed by the edit option and the unit’s name.
The command will launch the nano text editor, allowing you to edit the unit file specified.
NOTE: Unless necessary, AVOID editing critical unit files provisioned by the system.
Managing Services With systemctl
Unit files that end with .service are easy to manage using the systemd utility, systemctl. The following are operations we can perform with systemctl.
How to start services
To start a service with systemctl, we call the command:
In the above command, we told systemd to start the nginx service using the nginx.service unit file.
Passing the full unit file suffix with Systemctl is not a requirement. You can use the name of the service, such as:
In most service units, there is no output if the service starts successfully. However, if an error occurs, systemd will display the error and status code.
How to Stop Services
To stop a service, use the stop argument in the systemctl command
Similarly, the stop operation does not provide an output upon successful completion.
How to Reload services
Reloading a service works by stopping the worker processes, apply configuration changes and restart the worker processes. That does not shut down the actual service itself.
This feature can be helpful where services need to be online, as is the case with databases and web servers.
To reload a service in systemctl, we use the command:
How to Restart Services
On the other hand, restarting will shut down the service and the worker processes and restart them. The restart process may cause some downtime, making it very applicable when troubleshooting.
To restart a service, use the command:
How to Enable Services at Boot
If you want a specific service to run during system startup, you can use the enable command.
For example:
The above command, however, does not enable the service during an active session. To do this, add the –now flag.
If you want to enable a custom service you created, ensure that systemd can access the unit file. Do not store the unit file in /home directory. For custom unit files, ensure you place them in /etc/systemd/system.
How to Check Service Status
To check the status of a service in systemd, use the status command:
This command will show the current status of the service. The image below shows an active nginx service
If a service is stopped, you will get an output similar to the one shown below:
Conclusion
In this guide, we discussed the concepts of systemd and unit files. Systemd is a critical part of Linux, and major Linux distributions have now adopted its use. Therefore, knowing how to administer and manage can be very advantageous.