Whether you are a seasoned system administrator or a new Linux user, service management is one of the fundamental operations you must carry out. Hence, having a firm grasp of how services work and how to manage them is a great advantage.
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 the Systemd init service, allowing you to communicate with the systemd and perform operations.
Systemctl is a successor of the 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
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 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 categorized by the type of resource they represent. Systemd does this by appending the resource type as the suffix of the unit file.
The following are the unit files found in the 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 the 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
- .timer – Timer units define a timer managed and controlled by systemd for scheduled activation.
- .snapshot – Snapshot unit files allow rollback of the system's current state 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 dive deep into the Kernel.
List Unit Files
To view the unit files available in the system, you can list the files in
Luckily, systemd has a command for that. We can execute the command:
sudo systemctl list-units
Running this command will show the units available in the system.
You can use the
--type=[unit-type] option to filter only specific unit files. For example, to show service units files, we use the command:
sudo systemctl list-units --type=service
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:
sudo systemctl list-units –state=inactive
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
sudo systemctl list-units –all
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
sudo systemctl cat plymouth
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.
sudo systemctl edit plymouth
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:
sudo systemctl start nginx.service
In the above command, we told the systemd to start the
nginx service using the nginx.service unit file.
Passing the entire unit file suffix with Systemctl is not a requirement. You can use the name of the service, such as:
sudo systemctl start nginx
In most service units, there is no output if the service starts successfully. However, if an error occurs, the systemd will display the error and status code.
How to stop services
To stop a service, use the stop argument in the systemctl command
sudo systemctl stop nginx
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:
sudo systemctl reload nginx
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:
sudo systemctl restart nginx
How to enable services at boot
You can use the enable command if you want a specific service to run during system startup.
sudo systemctl enable nginx
The above command, however, does not enable the service during an active session. To do this, add the --now flag.
sudo systemctl enable nginx --now
If you want to enable a custom service you created, ensure that the systemd can access the unit file. Do not store the unit file in
/home directory. For custom unit files, ensure you place them in
How to check service status
To check the status of a service in systemd, use the status command:
sudo systemctl status nginx
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:
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.