# 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 customising 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 behaviour 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](https://www.ionos.com/en-ie/digitalguide/server/configuration/linux-commands-an-overview-of-terminal-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 recognise 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 recognise 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`. ```bash $ 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: ```bash $ sudo systemctl start application ``` For example, to start the Apache web server, you would enter: ```bash $ sudo systemctl start apache2 ``` If you want to stop a running service, use `stop`: ```bash $ sudo systemctl stop application.service ``` ### Restart and reload To restart a service, which is often necessary after a configuration change, use the `restart` command: ```bash $ 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: ```bash $ 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. ```bash $ 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: ```bash $ 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*. ```bash $ sudo systemctl enable application.service ``` To prevent a service from starting automatically when booting, use `disable`: ```bash $ 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: ```bash $ 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: ```bash $ 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. ```bash $ 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**: ```bash $ 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: ```bash $ 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. ```bash $ 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: ```bash $ 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: ```bash $ 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. ```bash $ 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 behaviour 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 : ```bash $ 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: ```bash $ 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: ```bash $ 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`: ```bash $ sudo systemctl unmask nginx.service ``` ## Editing of unit files systemctl has options to customise 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: ```bash $ 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: ```bash $ 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`: ```bash $ sudo rm -r /etc/systemd/system/nginx.service.d ``` A completely revised unit file can be deleted with the following command: ```bash $ 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: ```bash $ 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: ```bash $ 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: ```bash $ sudo systemctl set-default graphical.target ``` ### List available destinations To list all destinations available on your system, you can use the following command: ```bash $ 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. ```bash $ 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: ```bash $ 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`: ```bash $ sudo systemctl rescue ``` You can stop the system with `stop`: ```bash $ sudo systemctl stop ``` You can initiate a complete shutdown with `poweroff`: ```bash $ sudo systemctl poweroff ``` On the other hand, you can initiate a restart with `reboot`: ```bash $ 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: ```bash $ sudo reboot ``` This is a markdown version of: [https://www.ionos.com/en-ie/digitalguide/server/configuration/systemctl/](https://www.ionos.com/en-ie/digitalguide/server/configuration/systemctl/) for AI/LLM consumption.