systemd is a suite of tools that provide 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
To display the current system status type the following command:
$ systemctl status
It will return you a list of the status of all services on the server and their current state. 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 --state running
To get a list of all failed units, use the following command:
In case 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:
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
Mount points are translated automatically into their appropriate .mount unit. This means
/home is equivalent to
The same translation applies to devices, they are automatically translated into their corresponding .device unit. For example:
/dev/sda2 is equivalent to
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
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:
Systemd is able to manage the power states of the server.
To shut down and reboot the system, type:
To shut down and power-off the system, run the following command:
To suspend the system, type:
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:
To see only the log files since the current boot of the server use the option
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"
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: Starting A high performance web server and a reverse proxy server... Jul 10 10:01:29 my-server systemd: nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument Jul 10 10:01:29 my-server systemd: Started A high performance web server and a reverse proxy server. ...
To view all logs of a unit, use journald with the
journalctl -u unit
A Unit File contains the parameters that are used by systemd to manage and run a unit. It is a .ini-file inspired configuration file and consists of three main parts:
Unitsection contains generic information about the service.
Servicesection is about information about the service itself.
Installsection deals with the circumstances and triggers under which the service should be started.
Following an example of a simple Unit File:
[Unit] # "Description" will provide a general description of the service. Description=Foo # "After" allows to indicate which prerequisites are necessary for the operation of the service. In this example is indicated that the computer must have access to the Internet before the daemon is launched. After=network-online.target [Service] # "Type" allows to specify the type of the service. Type=simple # "User" and "Group" allow to specify the user and the group under which the service runs. User=foomaster Group=foogroup # "ExecStart" specifies the path and additional configuration parameters to the binary file. ExecStart=/usr/sbin/foo-daemon --config /etc/foo/config.txt # "Restart" defines the rule in which cases the service should be restarted. Restart=on-failure # "TimeoutStopSec" configures the time to wait before service is stopped forcefully. TimeoutStopSec=300 [Install] # "WantedBy" allows to specify in which Target must be active the service. WantedBy=multi-user.target
For more information how to write systemd Unit Files, you may refer to the offical manpage of systemd.
To explore the content of a Unit File, several options are available:
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.
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
systemctl edit --full unit
If you prefer to edit the file directly, without the above command, you have to reload systemd to enable the updated configuration:
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:
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
systemctl set-default multi-user.target
To get a list of all units bound to a target, type:
systemctl list-dependencies multi-user.target
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