---
title: Learning systemd essentials
description: Learn the essentials of systemd, a core component of Linux systems, and master its usage with our in-depth tutorial, covering key concepts and practical examples.
tags: systemd instances
products:
- instances
dates:
validation: 2025-05-19
posted: 2018-07-10
validation_frequency: 12
difficulty: beginner
usecase:
- best-practices
ecosystem:
- third-party
---
import Requirements from '@macros/iam/requirements.mdx'
`systemd` is a suite of tools that provides a fast and flexible init model for managing an entire machine from boot onwards. It provides a system and service manager that runs as PID 1 and controls the start of the rest of the system.
In recent years the majority of Linux distributions have adopted `systemd` as their default init system.
In this tutorial, you will learn a quick overview of the most important commands you will need to know for managing a `systemd` enabled server. These should work on any operating system that uses `systemd`.
- A Scaleway account logged into the [console](https://console.scaleway.com)
- [Owner](/iam/concepts/#owner) status or [IAM permissions](/iam/concepts/#permission) allowing you to perform actions in the intended Organization
- An [SSH key](/organizations-and-projects/how-to/create-ssh-key/)
- `sudo` privileges or access to the root user
## Analyzing the system state
To display the current **system status** type the following command:
```s
systemctl status
```
A list of the status of all services on the server and their current state will display. The report will look like the following sample:
```s
● my-server
State: running
Jobs: 0 queued
Failed: 0 units
Since: Tue 2018-07-10 09:30:33 UTC; 4min 21s ago
CGroup: /
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─dbus.service
│ └─273 /usr/bin/dbus-daemon --system --address=systemd: --nofork -
├─cron.service
│ └─266 /usr/sbin/cron -f
...
```
To list all running units, type the following command:
```s
systemctl list-units
```
To get a list of all failed units, use the following command:
```s
systemctl --failed
```
If there are any failed units, it will return a list like the following:
```s
root@my-server:~# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● apache2.service loaded failed failed The Apache HTTP Server
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
```
To get a list of all installed units, type the following command:
```s
systemctl list-unit-files
```
## Using units
The most common object that `systemd` manages and acts upon is a `unit`.
Units can be, for example, services (.service), devices (.device), mount points (.mount), or sockets (.socket).
You should always specify the complete name of the unit file, including its suffix (for example sshd.socket). A short form is available for .service files. For example `nginx` is equivalent to `nginx.service`.
Mount points are translated automatically into their appropriate .mount unit. This means `/home` is equivalent to `home.mount`.
The same translation applies to devices, they are automatically translated into their corresponding .device unit. For example: `/dev/sda2` is equivalent to `dev-sda2.device`.
Type the following command to **start** a unit immediately:
```s
systemctl start unit
```
Type the following command to **stop** a unit immediately:
```s
systemctl stop unit
```
If you want to **restart** a unit, type:
```s
systemctl restart unit
```
If you want to ask a unit to **reload** its configuration without interruption to the service, type:
```s
systemctl reload unit
```
This command can be handy if you have edited some configuration files of a service and do not want to restart it to reload the configuration.
If you want to know the **status** of a unit, including whether it is running or not, type:
```s
systemctl status unit
```
## Enabling or disabling units
The default configuration of most unit files does not let them start automatically at boot. To configure this behavior, the unit has to be "enabled".
This binds the unit to a specific boot "target", causing it to be triggered when the target is started.
To **check** whether a unit is already enabled or not, type:
```s
systemctl is-enabled unit
```
To **enable** a unit to be started on bootup, type the following command:
```s
systemctl enable unit
```
To **enable** a unit to be started on bootup and to **start** it immediately, run:
```s
systemctl enable --now unit
```
To **disable** a unit to not start during bootup:
```s
systemctl disable unit
```
Every service unit that is known to systemd may be started manually – even if it is disabled. To explicitly keep a service from running, use the **mask** command
This makes it impossible to start the concerned service either manually or as a dependency. Use it carefully.
```s
systemctl mask unit
```
To **unmask** a unit:
```s
systemctl unmask unit
```
To **reload** the systemd manager configuration and let it scan for new or changed units:
```s
systemctl daemon-reload
```
## Power management
Systemd can manage the power states of the server.
To shut down and **reboot** the system, type:
```s
systemctl reboot
```
To shut down and **power off** the system, run the following command:
```s
systemctl poweroff
```
To **suspend** the system, type:
```s
systemctl suspend
```
## Viewing system log information
Systemd provides a component called `journald`, that collects and manages journal entries from the whole system. It gathers log information from applications and the kernel.
To see all log information that `journald` has collected, type the following command. The logs are ordered from the latest to the oldest event:
```s
journalctl
```
To see only the log files since the current boot of the server use the option `-b`:
```s
journalctl -b
```
It is also possible to display all messages from a specific date (and optional time):
```s
journalctl --since="2012-10-30 18:17:16"
```
To see all messages since 20 minutes ago, type:
```s
journalctl --since "20 min ago"
```
## Checking unit states and logs
While the above commands give you access to the general system state, you can also get information about the state of individual units.
To see an overview of the current state of a unit, you can use the status option with the systemctl command. This will show you whether the unit is active, information about the process, and the latest journal entries:
```
systemctl status nginx.service
```
Besides the ability to get access to the general system state, you can also retrieve information about the state of an individual unit.
To get an overview of the state of a unit, the running sub-processes and the latest journal entries, type:
```s
systemctl status unit
```
For example, the output of a running Nginx web server:
```s
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-07-10 10:01:29 UTC; 24min ago
Process: 25327 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS)
Process: 25343 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
Process: 25335 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 25331 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 25339 (nginx)
CGroup: /system.slice/nginx.service
├─25339 nginx: master process /usr/sbin/nginx -g daemon on; master_process on
└─25345 nginx: worker process
Jul 10 10:01:29 my-server systemd[1]: Starting A high performance web server and a reverse proxy server...
Jul 10 10:01:29 my-server systemd[1]: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument
Jul 10 10:01:29 my-server systemd[1]: Started A high performance web server and a reverse proxy server.
...
```
To view all logs of a unit, use `journald` with the `-u` option:
```s
journalctl -u unit
```
## Exploring units and unit files
To explore the content of a unit file, some options are available.
A unit file contains the parameters that are used by systemd to manage and run a unit.
To see the full content of a unit file, type:
```s
systemctl cat unit
```
To get a dependency tree of a unit (a list of units that systemd attempts to activate when starting the unit), type the following command:
```s
systemctl list-dependencies unit
```
To see the low-level details of the settings which are used by the unit on the system, run the following command:
```s
systemctl show unit
```
This command will give you a list in return, showing each parameter being managed by systemd.
## Editing unit files
Systemctl allows you to edit unit files directly from the application, without needing to know the exact location of the file on the disk.
To add a snippet to an existing unit file, which can be used to append or overwrite configurations in the default unit file, type:
```s
systemctl edit unit
```
It is also possible to modify the entire content of the unit file instead of creating a snippet by using the `--full` flag:
```s
systemctl edit --full unit
```
Once edited, reload systemd to enable the updated configuration:
```s
systemctl daemon-reload
```
## Targets (runlevel)
An init system can handle the transition of the server itself between different states.
In systemd, these states are called **Targets**, which are synchronization points that the server can use to bring it into a specific state.
Unit files can be bound to a target and multiple targets can be active at the same time.
To see a list of all targets available on the system, type:
```s
systemctl list-unit-files --type=target
```
The default target that systemd tries to reach at boot (which will start all the unit files that use this target as a dependency) can be viewed by typing:
```s
systemctl get-default
```
You can change the default target that will be used at boot by using the set-default option:
The default target that will be used at boot can be changed with the `set-default` option:
```s
systemctl set-default multi-user.target
```
To get a list of all units bound to a target, type:
```s
systemctl list-dependencies multi-user.target
```
The `isolate` option will stop any units that are not bound to the specified target. Make sure that the target you are isolating does not stop any essential services:
```s
systemctl isolate multi-user.target
```