introduction to systemctl and unit files

Introduction

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.

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 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 /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 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.

1. .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.
2. .target – Target units provide synchronization points to other services during startup.
3. .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.
4. .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.
5. .device – Device unit configurations define a device unit as exposed in the sysfs/udev device tree.
6. .timer – Timer units define a timer managed and controlled by systemd for scheduled activation.
7. .snapshot – Snapshot unit files allow rollback of the system’s current state after making changes. We create them using the systemd snapshot command.
8. .swap – Swap units encode information about swap space, such as the device name or path of the swap space.
9. .mount – mount unit files encode information about mount points in the system managed by systemd.
10. .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 /lib/systemd/system or /etc/systemd/system.

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.

1. UNIT – The first column is the ‘UNIT.’ This shows the name of the unit file.
2. LOAD – This shows whether the unit definition loaded correctly.
3. ACTIVE – This shows the high-level activation state.
4. SUB – This shows the low-level activation state. The values in this column will depend on unit type.
5. DESCRIPTION – The unit file’s description.
6. 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

Output:

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.

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.

For example:

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 /etc/systemd/system.

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:

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.