Systemd
References
- Very interesting. Simple but complete overview.
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 (incl. boot), with coloring
Systemd startup
References:
man systemctl
- 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 withWantedBy=
,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 inman 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
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