Systemd

References

• SE - What starts units generated by generator
• Systemd: Service File Examples

Very interesting. Simple but complete overview.

• Systemd/User - archlinux

Command-line interface

systemctl list-unit-files     # List unit files installed and their status
systemctl                     # Show all loaded modules and their status
systemctl status              # Show all process and system status
systemctl list-dependencies   # Show dependencies between (currently loaded) units

journalctl -b                 # Kernel logs for this boot, with coloring (must be in group 'adm')
journalctl -b --user          # User related message
sudo SYSTEMD_COLORS=true journalctl -b > journal-boot.txt
                              # Log into file, with colors

Systemd startup

References:

• man systemctl
• man systemd.unit
• Stackexchange - generator

My own understanding on how systemd starts the system. Should find some tuto some days.

• unit is the generic name for something that is managed by systemd. A unit can be a service, a mount, a target...

systmctl list-units          # View units currently loaded in systemd memory
systmctl                     # Same

• A service is some piece of SW that can be started by systemd.
• A mount is like a mount point in fstab.
• A target is basically a group of service and mount points. Starting the target means starting the corresponding services and mount points.
• Dependencies between these targets, services, mounts are defined through Requires=, Requisite=, ConsistsOf=, Wants=, BindsTo= in unit files, or reversedly with WantedBy=, RequiredBy=, PartOf=, BoundBy=.
• Use systemctl list-unit-files to get all unit files in the system (enabled or not):

systemctl list-unit-files
systemctl list-unit-files init*

• See is-enabled section in man systemctl for unit file status:

"enabled"       Enabled via .wants, .requires or Alias= symlink,
                permanently in /etc/systemd/system or
                transiently in /run/systemd/system.
"generated"     Unit generated by a generator tool.
                See /run/systemd/generator or /run/systemd/generator.late
"masked"        Completely disabled.
                Usually /etc/systemd/system/foo.service pointing to /dev/null
                or broken link .../xyz.wants/foo.service

• Unit files are found in several locations:

ls /etc/systemd/system           # Some persistent unit files
ls /run/systemd/system           # Some transient unit files
ls /run/systemd/generator        # Unit created by the generator
ls /run/systemd/generator.late   # Unit created by the generator.late

• To be started, a unit file must be linked through a symlink in .wants or .requires folder.

l /etc/systemd/system/multi-user.target.wants/
# total 0
# lrwxrwxrwx 1 root root 35 Mar  7  2019 anacron.service -> /lib/systemd/system/anacron.service
# ...
# lrwxrwxrwx 1 root root 38 Mar 16  2019 borgcronic.service -> /etc/systemd/system/borgcronic.service

l /run/systemd/generator/local-fs.target.requires/
# lrwxrwxrwx 1 root root 17 Apr 25 01:55 boot-efi.mount -> ../boot-efi.mount
# lrwxrwxrwx 1 root root 13 Apr 25 01:55 boot.mount -> ../boot.mount
# ...

l /run/systemd/generator/local-fs.target.wants/
# lrwxrwxrwx 1 root root 45 Apr 25 01:55 systemd-fsck-root.service -> /lib/systemd/system/systemd-fsck-root.service
# lrwxrwxrwx 1 root root 46 Apr 25 01:55 systemd-remount-fs.service -> /lib/systemd/system/systemd-remount-fs.service

• For persistent unit, these links are generated in /etc/systemd/system when enabling a service:

systemctl enable foo              # Assume foo.service has a line "WantedBy=multi-user.target"
l /etc/systemd/system/multi-user.target.wants/foo.service
# lrwxrwxrwx 1 root root 38 Mar 16  2019 /etc/systemd/system/multi-user.target.wants/foo.service -> /etc/systemd/system/foo.service

• Transient links are made in /run/systemd/system, or can also be made by generators in /run/systemd/generator and /run/systemd/generator.late.

cat /run/systemd/generator.late/vmware.service 
# # Automatically generated by systemd-sysv-generator
# 
# [Unit]
# Documentation=man:systemd-sysv-generator(8)
# SourcePath=/etc/init.d/vmware
# Description=LSB: This service starts and stops VMware services

• Units are started at boot if systemd can find such peristent or transient symlinks.

Units

• systemd:0 means first systemd socket defined in the .socket file (FD 3), systemd:1 is the second (FD 4) and so on.

Example unit files

See Systemd: Service File Examples.

See man systemd.unit.

Configure a service to start at boot

sudo systemctl enable courier-authdaemon

Create a new service

From SE:

• Create a file /etc/systemd/system/foo.service

[Unit]
Description=foo

[Service]
ExecStart=/bin/bash -c "while true; do /bin/inotifywait -qq --event close_write /sys/class/backlight/acpi_video0/brightness; su myusername -c '/bin/xbacklight -display :0 -set $(cat /sys/class/backlight/acpi_video0/brightness)'; done"

[Install]
WantedBy=multi-user.target

Reload systemd:

systemctl daemon-reload

Enable the new service:

systemctl enable foo

This will create a symlink in /etc/systemd/system/multi-user.target.wants/, that will trigger the start of the service at next boot.

To start it immediately:

systemctl start foo
systemctl status foo # optional, just to verify

Example of options to add in the service file:

[Unit]
Description=rapid spam filtering system
After=nss-lookup.target

[Service]
ExecStart=/usr/bin/rspamd -c /etc/rspamd/rspamd.conf -f
User=_rspamd
RuntimeDirectory=rspamd
RuntimeDirectoryMode=0755
Restart=always

[Install]
WantedBy=multi-user.target

Edit unit file

For instance, to create an override for pipewire.socket (this creates file ~/.config/systemd/user/pipewire.socket.d/override.conf):

systemctl edit --user pipewire.socket
# [Socket]
# ExecStartPost=/bin/mount /mnt/pipewire/pipewire-0
# ExecStopPre=/bin/umount /mnt/pipewire/pipewire-0

Timers

Timers are a bit like cron job except they trigger systemd services, and have more scheduling and management options.

By default, a timer fires the service with the same name (see timer man page).

Power management (systemd-inhibit)

systemd-inhibit may be used to execute a program with a shutdown, sleep, or idle inhibitor lock taken. It allows you do disable only selected features and allows setting user visible string to explain why these features are inhibited [1]. See man systemd-inhibit

systemd-inhibit sleep 2h                                            # Prohibit idle, sleep, shutdown for 2 hours
systemd-inhibit wget "https://example.com/files/huge-download.dat"  # Same, while download ongoing

To list active inhibitors:

systemd-inhibit --list

How-to

Clean up /var/log/journal

To only keep the log of the last 10 days:

journalctl --vacuum-time=10d

To keep only 1G of journal logs:

journalctl --vacuum-size=1G

Force shutdown

See systemctl poweroff

Configure timeout a stop job is running for ...

Edit /etc/systemd/systemd.conf. For instance to set it to 30s:

DefaultTimeoutStopSec=30s