Systemd: Difference between revisions

From miki
Jump to navigation Jump to search
Line 11: Line 11:
journalctl -b # Kernel logs (incl. boot), with coloring
journalctl -b # Kernel logs (incl. boot), with coloring
</source>
</source>

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

References:
* <code>man systemctl</code>
* [https://unix.stackexchange.com/questions/332747/in-systemd-what-starts-units-generated-by-generator Stackexchange - generator]

* '''unit''' is the generic name for something that is managed by systemd. A ''unit'' can be a '''service''', a '''mount''', a '''target'''...
<source lang="bash">
systmctl list-units # View units currently loaded in systemd memory
systmctl # Same
</source>
* A '''service''' is some piece of SW that can be started by systemd.
* A '''mount''' is like a mount point in {{file|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 <code>Requires=</code>, <code>Requisite=</code>, <code>ConsistsOf=</code>, <code>Wants=</code>, <code>BindsTo=</code> in unit files, or reversedly with <code>WantedBy=</code>, <code>RequiredBy=</code>, <code>PartOf=</code>, <code>BoundBy=</code>.
* Use <code>systemctl list-unit-files</code> to get all unit files in the system (enabled or not):
<source lang="bash">
systemctl list-unit-files
systemctl list-unit-files init*
</source>
* See <code>is-enabled</code> section in <code>man systemctl</code> 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:
<source lang="bash">
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
</source>
* To be started, a unit file must be linked through a symlink in {{file|.wants}} or {{file|.requires}} folder.
<source lang="bash">
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
</source>
* For persistent unit, these links are generated in {{file|/etc/systemd/system}} when enabling a service:
<source lang="bash">
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
</source>
* Transient links are made in {{file|/run/systemd/system}}, or can also be made by generators in {{file|/run/systemd/generator}} and {{file|/run/systemd/generator.late}}.
<source lang="bash">
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
</source>
* Units are started at boot if systemd can find such peristent or transient symlinks.


== Services ==
== Services ==

Revision as of 11:26, 4 May 2020

References

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

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

References:

  • 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.

Services

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

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