Learning systemd essentials

• compute
• systemd
• server
• units

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

Before you start

To complete the actions presented below, you must have:

• A Scaleway account logged into the console
• Owner status or IAM permissions allowing you to perform actions in the intended Organization
• An SSH key
• sudo privileges or access to the root user

Analyzing the system state

To display the current system status type the following command:

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:

● 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:

systemctl list-units

To get a list of all failed units, use the following command:

systemctl --failed

If there are any failed units, it will return a list like the following:

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:

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:

systemctl start unit

Type the following command to stop a unit immediately:

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

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:

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:

systemctl status unit

For example, the output of a running Nginx web server:

● 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:

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:

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

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:

systemctl isolate multi-user.target