How to use systemctl to manage services and units

In Linux, systemctl plays a central role in the administration of the init system and service manager systemd. With systemctl, users have control over systemd services, its units and its configurations, making it an indispensable tool for system administration. From startup control to customizing system states, systemctl offers a comprehensive range of functions.

What is systemctl?

systemctl is a command-line tool for managing systemd, an init system and system manager for Linux operating systems. systemd is now the standard init system for several Linux distributions and Linux server distributions such as Ubuntu, Debian, Fedora, Red Hat Enterprise Linux (RHEL), CentOS, Arch Linux, Mageia and Gentoo. However, it is not implemented universally in all distributions.

In the systemd ecosystem, systemctl plays a central role in the management of system services, configuration, startup behavior and system maintenance. The functionality of the tool goes beyond simply starting and stopping services. It offers comprehensive management over almost all aspects of a Linux system.

In the following tutorial, you’ll find practical code examples and Linux commands for using systemctl. The examples below are based on Ubuntu 22.04.

Service management

The primary goal of the init system is to start the components that are required after booting the Linux kernel Linux kernel (userland components). The init system is also used to effectively control services and daemons on a server at any point during the system run.

Within systemd, most processes focus on resources that are managed by system. These are referred to as units. These units are classified according to the type of resource they represent and are defined by unit files. You can recognize the unit type by its file extension.

When managing services, the service units that end with the suffix .service are important. However, it’s not always necessary to use this suffix for service management commands. systemd is able to recognize that such commands generally refer to services.

Start and stop services

One of the most common tasks performed under Linux with systemctl is starting and stopping services. These functions are fundamental to system administration and allow you to maintain control over the processes that are running on a system. To start a service use the start command. If you are working as a user without root rights, you’ll have to use sudo.

$ sudo systemctl start application.service

Since systemd is designed to automatically search for .service files for service management commands, the command can also be entered in a simplified form:

$ sudo systemctl start application

For example, to start the Apache web server, you would enter:

$ sudo systemctl start apache2

If you want to stop a running service, use stop:

$ sudo systemctl stop application.service

Restart and reload

To restart a service, which is often necessary after a configuration change, use the restart command:

$ sudo systemctl restart application.service

If an application is able to reload its configuration files without restarting, the reload command can be used to initiate the process:

$ sudo systemctl reload application.service

If you are unsure whether a service offers the option to reload its configuration, you can use the reload-or-restart command. This will reload the configuration if this option is supported. If it’s not supported, the command will restart the service to initiate the update configuration.

$ sudo systemctl reload-or-restart application.service

Activate and deactivate services

By activating and deactivating services, you can specify whether a service should be started automatically when the system boots. This is particularly important for system performance, security and the management of dependencies between different services. Use the enable command to configure automatic activation at system startup:

$ sudo systemctl enable application.service

When this process is carried out, a symbolic link is created. This link connects the copy of the system service file. The system service file can usually be found under /lib/systemd/system or /etc/systemd/system. Here you’ll also find the directory on the hard disk where systemd searches for files for the autostart. This usually takes place under /etc/systemd/system/some_target.target.wants.

$ sudo systemctl enable application.service

To prevent a service from starting automatically when booting, use disable:

$ sudo systemctl disable application.service

Following this, the symbolic link that specifies automatic activation at startup will be deleted.

Caution: Simply activating a service will not immediately start it in the current session. To start the service immediately and configure it to start automatically on startup, you must execute both the start and enable commands.

Check the status of services

systemctl allows information about the status of services to be displayed. This is particularly useful for monitoring and diagnosing the current status of system and application services. Use the status command for the check:

$ systemctl status application.service

This command provides a range of information, including the current status of the service (active, inactive, faulty, etc.), the most recently executed processes and log messages, the cgroup hierarchy and the first log lines.

To check the current activity status of a service under Linux with systemctl, is-active is used. This command specifies whether a service is currently active or not:

$ systemctl is-active application.service

The current status is usually specified as active if the service is active, or inactive if the service is inactive.

To check whether a service is configured to be automatically enabled at system startup, you can use the is-enabled command. This is particularly useful for managing the start configuration of services on a Linux system.

$ systemctl is-enabled application.service

The command indicates whether the service is activated or deactivated and accordingly sets the exit code to “0” or “1” based on the response.

You can also use the is-failed command to check whether a specific service has an error status:

$ systemctl is-failed application.service

If execution is successful, active is output. If there is an error, it will be failed. If the unit was stopped intentionally, unknown or inactive may appear as the response. An exit status of 0 indicates an error has occurred, while 1 indicates any other status.

System status

The commands presented so far have focused on the management of individual services. These commands, however, don’t give insight into current system status. There are a variety of systemctl commands that can provide exactly this kind of information.

list-units is a useful for getting an overview of the current units on Linux:

$ systemctl list-units

When you execute this command, systemctl displays a list of units managed by systemd. The output of this list contains various columns with specific information about each unit. The following columns are displayed:

• UNIT: The name of the unit (This is often taken from the file name of the unit, e.g., sshd.service for the SSH daemon
• LOAD: Indicates whether the unit file was loaded successfully; possible values are loaded, not-found or error.
• ACTIVE: The activity status of the unit, which can alternate between modes such as active, inactive, activating or deactivating
• SUB: The subordinate activity status that gives further details on the state of the unit (For example, an active unit could have a SUB status of running, exited or failed.)
• DESCRIPTION: A brief description of the unit, often reflecting the purpose or functionality of the unit

However, the command defaults to only showing active units. For this reason, the LOAD column in the output typically shows loaded and the ACTIVE column active. With additional flags, systemctl can be configured so that it also displays additional information. For example, using the --all flag will display all units loaded by systemd regardless of their current activity status.

$ systemctl list-units --all

The output can further be refined by using additional flags such as --state= to filter specific states in the LOAD, ACTIVE or SUB categories. It is important to retain the --all flag so that inactive units are also displayed:

$ systemctl list-units --all --state=inactive

You can also use the filter --type= to display particular types of units, e.g., if you only want to see active service units:

$ systemctl list-units --type=service

List all unit files

To display a list of all unit files on Linux with systemctl (including those that systemd has not attempted to load), you can use list-unit-files. This command displays all unit files that systemd is aware of, including services, sockets, targets and more.

$ systemctl list-units-files

The command displays various states of unit files. These states indicate how the respective units are configured, in particular, with regard to their behavior at system startup. The most common states are

• Enabled: The unit is configured to be activated automatically at system startup.
• Disabled: The unit is not configured for automatic startup during the boot process.
• Masked: The unit is completely deactivated so that it cannot be started manually or automatically.
• Static: The unit is not started independently, but typically depends on another unit and is only started in this context.

Unit management

One of systemctl’s main jobs is the management of units. systemctl offers a range of useful commands and options that make it easier to obtain specific information about individual units and to manage them.

Display a unit file

If you want the content of a specific unit file to be displayed directly in the console, you can use the cat command. For example, to view the unit file of a service such as ssh.service, enter :

$ systemctl cat ssh.service

Display dependencies

If you use list-dependencies, the dependencies of a specific unit will be displayed in a tree structure. The command looks like this:

$ systemctl list-dependencies sshd.service

It’s standard for dependencies to be displayed for .target units that represent different system states. Use the --all flag for a complete, recursive list of all dependencies.

To display reverse dependencies (i.e., units that depend on the specified unit), add --reverse to the command. The flags --before and —after also allow you to see the dependencies that start before or after the unit in question.

Mask and unmask units

Masking a unit effectively disables it so that it cannot be started manually or automatically. This is often used to ensure that a service or unit is not started accidentally or automatically by dependencies. Masking is done by creating a symbolic link of the relevant unit file to /dev/null with the mask command:

$ sudo systemctl mask nginx.service

This ensures that the Nginx service cannot be started manually or automatically while it is in masked mode.

Unmasking removes the masked status from a unit so that it can be started again normally. The command for unmasking is unmask:

$ sudo systemctl unmask nginx.service

Editing of unit files

systemctl has options to customize and modify unit files. These functions were introduced with version 218 of systemd. If you use the edit command, a unit file in the selected unit is automatically opened for editing:

$ sudo systemctl edit nginx.service

When editing, an empty file is created to add or change specific instructions to a unit definition. For each unit (e.g., nginx.service), a subfolder is created in the /etc/systemd/system directory with .d appended to the name of the file. In the example above, the subfolder would be nginx.service.d.

An override.conf file is created in this subfolder. When systemd loads the unit, it combines the contents of this snippet file with the original unit file. Here the instructions of the snippet have priority. To process the entire unit file, the --full flag can be used:

$ sudo systemctl edit --full nginx.service

Pressing --full opens the existing unit file in an editor in order to make modifications. When exiting the editor, the system saves the edited file in /etc/systemd/system.

To undo changes you have made yourself, you can either delete the configuration directory .d of the unit or the modified file in /etc/systemd/system:

$ sudo rm -r /etc/systemd/system/nginx.service.d

A completely revised unit file can be deleted with the following command:

$ sudo rm /etc/systemd/system/nginx.service

After removing the file or directory, you will need to reload systemd so that it stops referencing the deleted files, instead reverting to the system’s own copy:

$ sudo systemctl daemon-reload

Adjustment of system state (runlevel) with targets

systemd primarily uses target to group different units together. This is done to achieve a specific system state, similar to runlevels in other init systems. The files with the suffix .target act as points of orientation, which indicate the availability status of certain functions. This enables users to specify the overall state desired, instead of the individual units required.

A practical example is swap.target, which marks the state of swap readiness. Units that are involved in the swap process can align themselves with this target using configuration options like WantedBy= or RequiredBy=. Units that rely on swap, on the other hand, can indicate this with settings such as Wants=, Requires= and After= to express their dependency and start order in relation to the swap.

Retrieve and set up default destination

Retrieving and setting up the default target allows you to define a default state for your system at startup. This is how you find the default target for your system:

$ systemctl get-default
Output
multi-user.target

If you want to change the default target, use the command set-default together with the name of the target. Use the following command to set the default target to graphical.target, which starts a graphical user interface:

$ sudo systemctl set-default graphical.target

List available destinations

To list all destinations available on your system, you can use the following command:

$ systemctl list-unit-files --type=target

This displays a list of all target unit files installed on your system. The path and current status (e.g., activated or deactivated) are displayed for each target.

Isolate targets

With isolate, you can simultaneously activate all units that are connected to a specific target and stop all other units not connected to it.

Let’s assume you are working in an environment with the active graphical.target and want to switch to a pure multi-user mode without a graphical user interface. In this case, you can deactivate the graphical system by isolating the multi-user.target. Since the graphical.target is dependent on the multi-user.target, but not vice versa, all graphical services are stopped when switching.

However, you should check the associated dependencies before isolating a target. This will prevent important processes from being stopped unintentionally.

$ systemctl list-dependencies multi-user.target

If you’ve checked the active units that you want to keep and agree with them, you can isolate the desired destination:

$ sudo systemctl isolate multi-user.target

Shortcuts for important events

There are specific targets for essential operations like shutting down or restarting the system. Under Linux, however, systemctl also offers practical shortcuts that provide additional functions. For example, to put the system into rescue mode (single-user mode), you can simply use rescue instead of isolate rescue.target:

$ sudo systemctl rescue

You can stop the system with stop:

$ sudo systemctl stop

You can initiate a complete shutdown with poweroff:

$ sudo systemctl poweroff

On the other hand, you can initiate a restart with reboot:

$ sudo systemctl reboot

If you’re logged in, these commands will inform you about upcoming events. Simply executing or isolating the target will not provide you with this information. It’s important to know that many computers will link the shorter commands for these actions with systemd to ensure correct execution.

The following command is normally sufficient for a system restart:

$ sudo reboot