Service management

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

sudo systemctl start app.service

sudo systemctl stop app.service

sudo systemctl restart app.service

sudo systemctl reload app.service

sudo systemctl reload-or-restart app.service

sudo systemctl enable app.service

sudo systemctl disable app.service

Checking status

1
2
3
4
5
6
7

systemctl status app.service

systemctl is-active app.service

systemctl is-enabled app.service

systemctl is-failed app.service

System state overview

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# see a list of active units
systemctl list-units

systemctl # returns same as above

systemctl list-units --all

systemctl list-units --all --state=inactive

systemctl list-units --type=service

To see every available units in the system paths (including those that systemd has not attempted to load):

1

systemctl list-unit-files

The state:

• enabled
• disabled
• static: means that the unit files does not contain an install section, which is used to enable a unit.
• masked:

Unit management

Show a unit file

To display the unit file that systemd has loaded into the system:

1

systemctl cat app.service

Display dependencies

To see a unit’s dependency tree:

1

systemctl list-depnedencies app.service

Using shortcuts for important events

Put the system into rescue (single-user) mode:

1

sudo systemctl rescue

To halt the system:

1

sudo systemctl halt

To initiate a full shutdown:

1

sudo systemctl poweroff

For restart:

1

sudo systemctl reboot

Listing available targets

A list of the available targets:

1

systemctl list-unit-files --type=target

Unlike runlevels, multiple targets can be active at one time. An active target indicates that systemd has attempted to start all of the units tied to the target and has not tried to tear them down again.

To see all of the active targets:

1

systemctl list-units --type=target

Default target

To find the default target for system:

1

systemctl get-default

To set different default target:

1

sudo systemctl set-default graphical.target

Editing unit files

Edit unit file:

1

sudo systemctl edit app.service

This will be a blank file that can be used to override or add directives to the unit definition. A directory will be created within the /etc/systemd/system directory which contains the name of the unit with .d appended. For instance, for the nginx.service, a directory called nginx.service.d will be created.

Within this directory, a snippet will be created called override.conf. When the unit is loaded, systemd will, in memory, merge the override snippet with the full unit file. The snippet’s directives will take precedence over those found in the original unit file.

To edit the full unit file instead of creating a snippet:

1

sudo systemctl edit --full nginx.service

After editing, deleting file or directory:

1

sudo systemctl daemon-reload

Check unit properties

To see the low-level properties of a unit:

1

systemctl show app.service

To see the conflicts:

1

systemctl show app.service -p conflicts

Masking or unmasking units

1

sudo systemctl mask app.service

To mark a unit as completely unstartable, automatically or manually, by linking it to /dev/null, we can mask the unit.

To unmask:

1

sudo systemctl unmask app.service