By clicking or navigating this website site, you agree to allow our collection of information on Scaleway to offer you an optimal user experience and to keep track of statistics through cookies. Learn more about our Cookie Policy.

Learn Systemd essentials

Systemd Overview

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 which 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’ll need to know for managing a systemd enabled server. These should work on any operating system that uses systemd.

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.

To start a unit immediately, type the following command:

systemctl start unit

To stop a unit immediately, type:

systemctl stop unit

If you want to restart a unit, type:

systemctl restart unit

If you want to ask a unit to reload its configuration without interruption to the service, type:

systemctl reload unit

This command can be handy, in case you have edited some configuration files of a service and you don’t 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:

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 behaviour, 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:

systemctl is-enabled unit

To enable a unit to be started on bootup, type the following command:

systemctl enable unit

To enable a unit to be started on bootup and to start it immediately, run:

systemctl enable --now unit

To disable a unit to not start during bootup:

systemctl disable unit

Every service unit that is known to systemd may be started manually – even if it is disabled. To explicitly avoid that a service runs, use the mask command (Attention: This makes it impossible to start the concerned service. Neither manually nor as a dependency. Use it carefully.):

systemctl mask unit

To unmask a unit:

systemctl unmask unit

To reload the systemd manager configuration and letting it scan for new or changed units:

systemctl daemon-reload

Power Management

Systemd is able to manage the power states of the server.

To shut down and reboot the system, type:

systemctl reboot

To shut down and power-off the system, run the following command:

systemctl poweroff

To suspend the system, type:

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:

journalctl

To see only the log files since the current boot of the server use the option -b:

journalctl -b

It is also possible to display all messages from a specific date (and optional time):

journalctl --since="2012-10-30 18:17:16"

To see all messages since 20 minutes ago, type:

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:

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:

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:

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:

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:

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:

systemctl edit --full unit

Once edited, reload systemd to enable the updated configuration:

systemctl daemon-reload

Targets (Runlevel)

An init system can handle the transition of the server itself between different states. In systemd theses 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:

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:

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:

systemctl set-default multi-user.target

To get a list of all units bound to a target, type:

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: