15 Der Daemon systemd #

Eine Unit-Konfigurationsdatei enthält Informationen zu einem Dienst, Socket, Gerät, Einhängepunkt, Automount-Punkt, einer Auslagerungsdatei oder Partition, einem Startziel, einem überwachten Dateisystempfad, einem von systemd gesteuerten und überwachten Zeitgeber, einem Snapshot eines temporären Systemstatus, einem Ressourcenverwaltungs-Slice oder einer Gruppe extern erstellter Prozesse.

„Unit-Datei“ ist in systemd ein generischer Term für Folgendes:

Weitere Informationen zu systemd-Unit-Dateien finden Sie in http://www.freedesktop.org/software/systemd/man/systemd.unit.html

Die Subkommandos zum Verwalten der Dienste sind mit den entsprechenden Kommandos in System V-init identisch (start, stop usw.). Die allgemeine Syntax für Dienstverwaltungskommandos lautet wie folgt:

Mit systemd können Sie mehrere Dienste gleichzeitig verwalten. Im Gegensatz zu System V-init, bei dem die init-Skripts einzeln nacheinander ausgeführt werden, führen Sie ein einziges Kommando aus, beispielsweise:

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

So rufen Sie eine Liste aller auf dem System verfügbaren Dienste ab:

tux > sudo systemctl list-unit-files --type=service

Die folgende Tabelle zeigt die wichtigsten Dienstverwaltungskommandos für systemd und System V-init:

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

Mit den Dienstverwaltungskommandos im vorangegangenen Abschnitt können Sie die Dienste für die aktuelle Sitzung bearbeiten. Mit systemd können Sie Dienste außerdem dauerhaft aktivieren oder deaktivieren, so dass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Kommandozeile tun.

15.2.2.1 Aktivieren/Deaktivieren von Diensten über die Kommandozeile #

 

Die folgende Tabelle zeigt die wichtigsten Aktivierungs- und Deaktivierungskommandos für systemd und System V-init:

Wichtig: Dienststart

Wenn ein Dienst über die Kommandozeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Soll ein Dienst nach dem Aktivieren sofort gestartet werden, führen Sie explizit systemctl start MEIN_DIENST oder rc MEIN_DIENST start aus.

Tabelle 15.2: Kommandos zum Aktivieren und Deaktivieren von Diensten #

 

Aufgabe	systemd-Kommando	System V-init-Kommando
Aktivieren.	systemctl enable MEIN(E)_DIENST(E)	insserv MEIN(E)_DIENST(E), chkconfig -a MEIN(E)_DIENST(E)
Deaktivieren.	systemctl disable MEIN(E)_DIENST(E).service	insserv -r MEIN(E)_DIENST(E), chkconfig -d MEIN(E)_DIENST(E)
Überprüfen.  Zeigt an, ob ein Dienst aktiviert ist oder nicht.	systemctl is-enabled MEIN_DIENST	chkconfig MEIN_DIENST
Erneut aktivieren.  Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieses Kommando einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll.	systemctl reenable MEIN_DIENST	n/v
Maskierung.  Nach dem „Deaktivieren“ eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst vollständig deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden.	systemctl mask MEIN_DIENST	n/v
Demaskieren.  Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde.	systemctl unmask MEIN_DIENST	n/v

Bei System V-init wurde das System in ein sogenanntes „Runlevel“ gebootet. Ein Runlevel definiert, wie das System gestartet wird und welche Dienste im laufenden System verfügbar sind. Die Runlevels sind numeriert. Die bekanntesten Runlevels sind 0 (System herunterfahren), 3 (Mehrbenutzermodus mit Netzwerk) und 5 (Mehrbenutzermodus mit Netzwerk und Anzeigemanager).

systemd führt mit den sogenannten „Ziel-Units ein neues Konzept ein“. Dennoch bleibt die Kompatibilität mit dem Runlevel-Konzept uneingeschränkt erhalten. Die Ziel-Units tragen Namen statt Zahlen und erfüllen bestimmte Zwecke. Mit den Zielen local-fs.target und swap.target werden beispielsweise lokale Dateisysteme und Auslagerungsbereiche eingehängt.

Das Ziel graphical.target stellt ein Mehrbenutzersystem mit Netzwerk sowie Anzeigemanager-Funktionen bereit und entspricht Runlevel 5. Komplexe Ziele wie graphical.target fungieren als „Metaziele“, in denen eine Teilmenge anderer Ziele vereint ist. Mit systemd können Sie problemlos vorhandene Ziele kombinieren und so benutzerdefinierte Ziele bilden. Damit bietet dieses Kommando eine hohe Flexibilität.

Die nachfolgende Liste zeigt die wichtigsten systemd-Ziel-Units. Eine vollständige Liste finden Sie in man 7 systemd.special.

Damit die Kompatibilität mit dem Runlevel-System von System V-init gewährleistet bleibt, bietet systemd besondere Ziele mit der Bezeichnung runlevelX.target, denen die entsprechenden, mit X nummerierten Runlevels zugeordnet sind.

Mit dem Kommando systemctl get-default ermitteln Sie das aktuelle Ziel.

Wichtig: systemd ignoriert /etc/inittab

Die Runlevels in einem System V-init-System werden in /etc/inittab konfiguriert. Bei systemd wird diese Konfiguration nicht verwendet. Weitere Anweisungen zum Erstellen eines bootfähigen Ziels finden Sie unter Abschnitt 15.5.4, „Erstellen von benutzerdefinierten Zielen“.

systemd bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Services mit dem jeweiligen Status prüfen (ohne durch /var/log/ blättern zu müssen). Mit systemd können Sie zudem den Startvorgang scannen und so ermitteln, wie lang das Starten der einzelnen Dienste dauert.

root # systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
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.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

root # systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

tux > dmesg -T | less

systemd ist mit System V kompatibel, sodass Sie vorhandene System V-init-Skripte weiterhin nutzen können. Es gibt allerdings mindestens ein bekanntes Problem, bei dem ein System V-init-Skript nicht ohne Weiteres mit systemd zusammenarbeitet: Wenn Sie einen Dienst als ein anderer Benutzer über su oder sudo in init-Skripten starten, tritt der Fehler „Access denied“ (Zugriff verweigert) auf.

Wenn Sie den Benutzer mit su oder sudo ändern, wird eine PAM-Sitzung gestartet. Diese Sitzung wird beendet, sobald das init-Skript abgeschlossen ist. Als Folge wird auch der Service, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor:

Zum Anpassen von Unit-Dateien wird das Kommando systemctl edit DIENST empfohlen. Dieses Kommando startet den Standardtexteditor und erstellt ein Verzeichnis mit der Datei override.conf file unter /etc/systemd/system/NAME.service.d/. Das Kommando benachrichtigt außerdem den laufenden systemd-Vorgang über die Änderungen.

Alternativ können Sie mit dem Kommando systemctl edit --full DIENST eine Kopie der Originaldatei zum Bearbeiten anstelle einer leeren Datei öffnen. Achten Sie beim Bearbeiten der Datei darauf, alle vorhandenen Abschnitte beizubehalten.

Ändern Sie als Übung den Zeitraum, den das System auf den Start von MariaDB warten soll. Führen Sie als root das Kommando systemctl edit --full mariadb.service aus. Die geöffnete Datei ist in etwa wie folgt aufgebaut:

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

# Configures the time to wait for start-up/stop
TimeoutSec=300

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

Passen Sie den Wert für TimeoutSec an und speichern Sie die Änderungen. Zum Aktivieren der Änderungen führen Sie als root das Kommando systemctl daemon-reload aus.

Weitere Informationen finden Sie auf den man-Seiten, die Sie mit dem Kommando man 1 systemctl aufrufen können.

Bei kleineren Änderungen an einer Konfigurationsdatei verwenden Sie sogenannte Drop-in-Dateien. Mit den Drop-in-Dateien erweitern Sie die Konfiguration von Unit-Dateien, ohne die Unit-Dateien selbst bearbeiten oder überschreiben zu müssen.

Um beispielsweise einen einzigen Wert für den Dienst foobar in /usr/lib/systemd/system/ foobar.service zu ändern, gehen Sie wie folgt vor:

Anmerkung: Vermeiden von Namenskonflikten

Um Namenskonflikte zwischen Ihren Drop-in-Dateien und den von SUSE bereitgestellten Dateien zu vermeiden, wird empfohlen, allen Drop-in-Dateinamen eine zweistellige Zahl und einen Bindestrich voranzustellen, beispielsweise 80-override.conf.

Die folgenden Bereiche sind reserviert:

• 0-19 ist für systemd-Upstream reserviert

• 20-25 ist für systemd reserviert (von SUSE bereitgestellt)

• 26-29 ist für SUSE-Pakete reserviert (außer systemd)

• 50 ist für Drop-in-Dateien reserviert, die mit systemctl set-property erstellt werden.

Geben Sie eine zweistellige Zahl oberhalb dieses Bereichs an, damit die von SUSE bereitgestellten Drop-in-Dateien Ihre eigenen Drop-in-Dateien nicht überschreiben.

Mit systemctl cat $UNIT können Sie die Dateien auflisten und überprüfen, die in der Unit-Konfiguration berücksichtigt werden.

Seit der Version SUSE Linux Enterprise Server 15 wurde die xinetd-Infrastruktur entfernt. In diesem Abschnitt wird beschrieben, wie Sie vorhandene benutzerdefinierte xinetd-Dienstdateien in systemd-Sockets konvertieren.

Für jede xinetd-Dienstdatei benötigen Sie mindestens zwei systemd-Unit-Dateien: die Socket-Datei (*.socket) und eine zugehörige Dienstdatei (*.service). Die Socket-Datei weist systemd an, welcher Socket erstellt werden soll, und die Dienstdatei weist systemd an, welche ausführbare Datei gestartet werden soll.

Betrachten Sie das folgende Beispiel für eine xinetd-Dienstdatei:

root # cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

Zum Konvertieren in systemd benötigen Sie die folgenden beiden Dateien:

root # cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

root # cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

Eine vollständige Liste der Socket- und Dienstdateioptionen für systemd finden Sie auf den man-Seiten zu systemd.socket und systemd.service (man 5 systemd.socket, man 5 systemd.service).

Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, so dass die Administratoren eine eigene Runlevel-Konfiguration erstellen können. Mit systemd können Sie beliebig viele benutzerdefinierte Ziele erstellen. Zum Einstieg sollten Sie ein vorhandenes Ziel anpassen, beispielsweise graphical.target.

systemd unterstützt das regelmäßige Bereinigen der temporären Verzeichnisse. Die Konfiguration aus der bisherigen Systemversion wird automatisch migriert und ist aktiv. tmpfiles.d (verwaltet temporäre Dateien) liest die Konfiguration aus den Dateien /etc/tmpfiles.d/*.conf, /run/tmpfiles.d/*.conf und /usr/lib/tmpfiles.d/*.conf aus. Die Konfiguration in /etc/tmpfiles.d/*.conf hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In /usr/lib/tmpfiles.d/*.conf speichern die Pakete die Konfigurationsdateien.)

Im Konfigurationsformat ist eine Zeile pro Pfad vorgeschrieben, wobei diese Zeile die Aktion und den Pfad enthalten muss und optional Felder für Modus, Eigentümer, Alter und Argument (je nach Aktion) enthalten kann. Im folgenden Beispiel wird die Verknüpfung der X11-Sperrdateien aufgehoben:

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

So rufen Sie den Status aus dem tmpfile-Zeitgeber ab:

tux > sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

Weitere Informationen zum Arbeiten mit temporären Dateien finden Sie unter man 5 tmpfiles.d.

In Abschnitt 15.6.9, „Fehlersuche für Dienste“ wird erläutert, wie Sie Protokollmeldungen für einen bestimmten Dienst anzeigen. Die Anzeige von Protokollmeldungen ist allerdings nicht auf Dienstprotokolle beschränkt. Sie können auch auf das gesamte von systemd geschriebene Protokoll (das sogenannte „Journal“) zugreifen und Abfragen darauf ausführen. Mit dem Befehl journalctl zeigen Sie das gesamte Protokoll an, beginnend mit den ältesten Einträgen. Informationen zu weiteren Optionen, beispielsweise zum Anwenden von Filtern oder zum Ändern des Ausgabeformats, finden Sie unter man 1 journalctl.

Mit dem Subkommando isolate können Sie den aktuellen Status von systemd als benannten Snapshot speichern und später wiederherstellen. Dies ist beim Testen von Diensten oder benutzerdefinierten Zielen hilfreich, weil Sie jederzeit zu einem definierten Status zurückkehren können. Ein Snapshot ist nur in der aktuellen Sitzung verfügbar; beim Neubooten wird er automatisch gelöscht. Der Snapshot-Name muss auf .snapshot enden.

Mit systemd können Kernel-Module automatisch zum Bootzeitpunkt geladen werden, und zwar über die Konfigurationsdatei in /etc/modules-load.d. Die Datei sollte den Namen MODUL.conf haben und den folgenden Inhalt aufweisen:

# load module MODULE at boot time
MODULE

Falls ein Paket eine Konfigurationsdatei zum Laden eines Kernel-Moduls installiert, wird diese Datei unter /usr/lib/modules-load.d installiert. Wenn zwei Konfigurationsdateien mit demselben Namen vorhanden sind, hat die Datei unter /etc/modules-load.d Vorrang.

Weitere Informationen finden Sie auf der man-Seite modules-load.d(5).

Bei System V mussten init-Aktionen, die vor dem Laden eines Diensts ausgeführt werden müssen, in /etc/init.d/before.local festgelegt werden. Dieses Verfahren wird in systemd nicht mehr unterstützt. Wenn Aktionen vor dem Starten von Diensten ausgeführt werden müssen, gehen Sie wie folgt vor:

Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde. Einige Dienste (z. B. Apache) erzeugen zahlreiche externe Prozesse (z. B. CGI- oder Java-Prozesse), die wiederum weitere Prozesse erzeugen. Eindeutige Zuweisungen sind damit schwierig oder völlig unmöglich. Wenn ein Dienst nicht ordnungsgemäß beendet wird, bleiben zudem ggf. einige untergeordnete Dienste weiterhin aktiv.

Bei systemd wird jeder Dienst in eine eigene cgroup aufgenommen, womit dieses Problem gelöst ist. cgroups sind eine Kernel-Funktion, mit der die Prozesse mit allen ihren untergeordneten Prozessen in hierarchisch strukturierten Gruppen zusammengefasst werden. Die cgroups werden dabei nach dem jeweiligen Dienst benannt. Da ein nicht privilegierter Dienst seine cgroup nicht „verlassen“ darf, ist es damit möglich, alle von einem Dienst erzeugten Prozesse mit dem Namen dieses Dienstes zu versehen.

Mit dem Kommando systemd-cgls erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören. (Gekürztes) Beispiel für die Ausgabe:

root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

Weitere Informationen zu cpgroups finden Sie im Chapter 10, Kernel control groups.

Wie in Abschnitt 15.6.6, „Kernel-Steuergruppen (cgroups)“ erläutert, kann ein Prozess in einem System-V-init-System nicht immer eindeutig seinem übergeordneten Dienstprozess zugeordnet werden. Das erschwert das Beenden eines Dienstes und seiner untergeordneten Dienste. Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als "Zombie-Prozess" zurück.

Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Dienstes eindeutig erkannt werden, sodass Sie ein Signal zu diesen Prozessen senden können. Mit Use systemctl kill senden Sie die Signale an die Dienste. Eine Liste der verfügbaren Signale finden Sie in man 7 signals.

Der D-Bus-Dienst fungiert als Meldungsbus für die Kommunikation zwischen den systemd-Clients und dem systemd-Manager, der als PID 1 ausgeführt wird. dbus ist zwar ein eigenständiger Dämon, bildet jedoch auch einen wesentlichen Bestandteil der init-Infrastruktur.

Das Beenden von dbus oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu beenden oder neu zu starten. Hiermit wird die systemd-Client/Server-Kommunikation unterbrochen, sodass die meisten systemd-Funktionen unbrauchbar werden.

Das Beenden oder Neustarten von dbus wird daher weder empfohlen noch unterstützt.

Nach einer Aktualisierung von dbus oder dbus-Paketen fällt ein Neustart an. Wenn Sie sich nicht sicher sind, ob ein Neustart erforderlich ist, führen Sie den Befehl sudo zypper ps -s aus. Ist dbus unter den aufgelisteten Diensten zu finden, müssen Sie das System neu starten.

Beachten Sie, dass dbus selbst dann aktualisiert wird, wenn in der Konfiguration der automatischen Aktualisierungen festgelegt ist, dass die Pakete, die einen Neustart erfordern, übersprungen werden sollen.

Standardmäßig ist die Ausgabe von systemd auf ein Minimum beschränkt. Wenn ein Dienst ordnungsgemäß gestartet wurde, erfolgt keine Ausgabe. Bei einem Fehler wird eine kurze Fehlermeldung angezeigt. Mit systemctl status können Sie jedoch die Fehlersuche für den Start und die Ausführung eines Dienstes vornehmen.

systemd umfasst einen Protokollierungsmechanismus („Journal“), mit dem die Systemmeldungen protokolliert werden. Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen. Das Kommando status hat eine ähnliche Funktion wie tail und kann zudem die Protokollmeldungen in verschiedenen Formaten anzeigen, ist also ein wirksames Hilfsmittel für die Fehlersuche.

Zeitgeber-Units können monotone Zeitgeber und Echtzeit-Zeitgeber nutzen.

Für jede Zeitgeber-Unit muss eine entsprechende systemd-Unit-Datei vorliegen, die durch die Zeitgeber-Unit gesteuert wird. Anders gesagt, eine .timer-Datei aktiviert und verwaltet die zugehörige .service-Datei. Wird eine .service-Datei mit einem Zeitgeber verwendet, muss die Datei keinen Abschnitt [Install] enthalten, da der Dienst durch den Zeitgeber verwaltet wird.

Zur Veranschaulichung der Grundlagen von systemd-Zeitgeber-Units soll ein Zeitgeber eingerichtet werden, der das Shell-Skript foo.sh auslöst.

Im ersten Schritt erstellen Sie eine systemd-Dienst-Unit, die das Shell-Skript steuert. Öffnen Sie hierzu eine neue Textdatei zum Bearbeiten und fügen Sie folgende Dienst-Unit-Definition hinzu:

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

Speichern Sie die Datei unter dem Namen foo.service im Verzeichnis /etc/systemd/system/.

Öffnen Sie dann eine neue Textdatei zum Bearbeiten und fügen Sie folgende Zeitgeberdefinition hinzu:

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

Der Abschnitt [Timer] im obigen Beispiel gibt an, welcher Dienst (foo.service) zu welchem Zeitpunkt ausgelöst werden soll. In diesem Fall gibt die Option OnBootSec einen monotonen Zeitgeber an, der den Dienst fünf Minuten nach Systemstart auslöst, während die Option OnUnitActiveSec den Dienst 24 Stunden nach Aktivierung des Dienstes auslöst (der Zeitgeber löst den Dienst also einmal täglich aus). Die Option WantedBy gibt schließlich an, dass der Zeitgeber gestartet werden soll, sobald das System das Mehrbenutzerziel erreicht hat.

Anstelle eines monotonen Zeitgebers können Sie mit der Option OnCalendar einen Echtzeit-Zeitgeber angeben. Die folgende Echtzeit-Zeitgeberdefinition löst die zugehörige Dienst-Unit einmal wöchentlich aus, beginnend am Montag um 12:00 Uhr.

[Timer]
OnCalendar=weekly
Persistent=true

Die Option Persistent=true gibt an, dass der Dienst sofort nach Aktivierung des Zeitgebers ausgelöst wird, falls der Zeitgeber die letzte Startzeit versäumt hat (z. B. weil das System ausgeschaltet war).

Mit der Option OnCalendar können außerdem bestimmte Zeitpunkte (Datum und Uhrzeit) für die Auslösung eines Dienstes im folgenden Format definiert werden: Wochentag Jahr-Monat-Tag Stunde:Minute:Sekunde. Im folgenden Beispiel wird ein Dienst täglich um 5:00 Uhr gestartet:

OnCalendar=*-*-* 5:00:00

Ein Sternchen bezeichnet einen beliebigen Wert und mögliche Werte können durch Komma getrennt aufgelistet werden. Zwei Werte, die durch zwei Punkte (..) getrennt sind, geben einen zusammenhängenden Bereich an. Im folgenden Beispiel wird ein Dienst an jedem Freitag im Monat um 18:00 Uhr gestartet:

OnCalendar=Fri *-*-1..7 18:00:00

Soll ein Dienst zu verschiedenen Zeiten ausgelöst werden, können Sie mehrere OnCalendar-Einträge angeben:

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

Im obigen Beispiel wird ein Dienst an Wochentagen um 10:00 Uhr und am Wochenende um 22:00 Uhr ausgelöst.

Wenn Sie die Zeitgeber-Unit-Datei bearbeitet haben, speichern Sie sie unter dem Namen foo.timer im Verzeichnis /etc/systemd/system/. Prüfen Sie die erstellten Unit-Dateien mit folgendem Kommando:

tux > sudo  systemd-analyze verify /etc/systemd/system/foo.*

Wenn das Kommando keine Ausgabe zurückgibt, haben die Dateien die Überprüfung erfolgreich bestanden.

Starten Sie den Zeitgeber mit dem Kommando sudo systemctl start foo.timer. Soll der Zeitgeber beim Starten aktiviert werden, führen Sie das Kommando sudo systemctl enable foo.timer aus.

Da Zeitgeber wie normale systemd-Units behandelt werden, können Sie sie mit systemctl verwalten. Sie können einen Zeitgeber mit systemctl start starten, mit systemctl enable aktivieren usw. Außerdem können Sie mit dem Kommando systemctl list-timers alle aktiven Zeitgeber auflisten. Mit dem Kommando systemctl list-timers --all werden alle Zeitgeber aufgelistet, auch wenn sie inaktiv sind.