Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Desktop-Dokumentation / Verwaltungshandbuch / Booten eines Linux-Systems / Der Daemon systemd
Gilt für SUSE Linux Enterprise Desktop 15 SP6

19 Der Daemon systemd

systemd initialisiert das System. Er hat die Prozess-ID 1. systemd wird direkt vom Kernel gestartet und widersteht dem Signal 9, das in der Regel Prozesse beendet. Alle anderen Programme werden direkt von systemd oder von einem seiner untergeordneten Prozesse gestartet. systemd ist ein Ersatz für den Daemon „System V-init“ und vollständig mit System V-init kompatibel (durch Unterstützung von init-Skripten).

Der wichtigste Vorteil von systemd ist der erheblich schnellere Systemstart durch die Parallelisierung der Dienststarts. Darüber hinaus startet systemd einen Dienst nur dann, wenn er tatsächlich benötigt wird. Deamons werden nicht in jedem Fall beim Booten gestartet, sondern erst dann, wenn sie erstmalig benötigt werden. systemd unterstützt auch Kernel-Steuergruppen (cgroups), das Erstellen von Snapshots und das Wiederherstellen des Systemstatus. Weitere Einzelheiten finden Sie unter https://www.freedesktop.org/wiki/Software/systemd/.

Tipp
Tipp: systemd innerhalb des WSL

Das Windows-Subsystem für Linux (WSL) ermöglicht die Ausführung von Linux-Anwendungen und -Distributionen unter dem Betriebssystem Microsoft Windows. WSL verwendet seinen init-Prozess anstelle von systemd. Um systemd in SLED zu aktivieren, das unter WSL ausgeführt wird, installieren Sie das wsl_systemd-Schema, das den Prozess automatisiert:

> sudo zypper in -t pattern wsl_systemd

Alternativ können Sie /etc/wsl.conf bearbeiten und die folgenden Zeilen manuell hinzufügen:

[boot]
systemd=true

Beachten Sie, dass die Unterstützung für systemd unter WSL teilweise ist – systemd-Unit-Dateien müssen ein angemessenes Prozessverwaltungsverhalten aufweisen.

19.1 Das Konzept von systemd

Im folgenden Abschnitt wird das Konzept hinter systemd erläutert.

systemd ist ein System- und Sitzungsmanager für Linux und mit System V- und LSB-init-Skripts kompatibel. Die wichtigsten Funktionen von systemd:

  • Parallelisierungsfunktionen

  • Starten von Diensten per Socket- und D-Bus-Aktivierung

  • Starten der Daemons bei Bedarf

  • Verfolgen von Prozessen mithilfe von Linux-cgroups

  • Erstellen von Snapshots und Wiederherstellen des Systemstatus

  • Einhängepunkte und Automount-Punkte

  • Ausgereifte Dienststeuerlogik auf der Basis der Transaktionsabhängigkeiten

19.1.1 Unit-Datei

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-Dateisystemd ist in ein generischer Term für Folgendes:

  • Service.  Informationen zu einem Prozess (z. B. Ausführung eines Daemon); Datei endet auf .service

  • Zielgruppen.  Fassen Units zu Gruppen zusammen bzw. fungieren als Synchronisierungspunkte beim Starten; Datei endet auf .target

  • Sockets.  Informationen zu einem IPC- oder Netzwerk-Socket oder einem Dateisystem-FIFO, für die socketbasierte Aktivierung (wie inetd); Datei endet auf .socket

  • Path.  Dient als Auslöser von anderen Units (z. B. Ausführen eines Diensts, wenn Dateien geändert werden); Datei endet auf .path

  • Zeitgeber.  Informationen zu einem gesteuerten Zeitgeber für die zeitgeberbasierte Aktivierung; Datei endet auf .timer

  • Einhängepunkt.  In der Regel automatisch durch den fstab-Generator erzeugt; Datei endet auf .mount

  • Automount-Punkt.  Informationen zu einem Dateisystem-Automount-Punkt; Datei endet auf .automount

  • Swap.  Informationen zu einem Auslagerungsgerät oder einer Auslagerungsdatei für das Arbeitsspeicher-Paging; Datei endet auf .swap

  • Gerät.  Informationen zu einer Geräte-Unit in der Geräte-Baumstruktur sysfs/udev(7); Datei endet auf .device

  • Bereich/Slice.  Konzept für die hierarchische Verwaltung von Ressourcen einer Prozessgruppe; Datei endet auf .scope/.slice

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

19.2 Grundlegende Verwendung

Im System V-init-System werden Dienste mit mehreren Befehlen verarbeitet – mit init-Skripten, insserv, telinit und anderen. systemd Vereinfacht die Verwaltung von Diensten, da es nur einen Befehl gibt, um die meisten dienstbezogenen Aufgaben zu erledigen: systemctl Hierbei gilt die Syntax Befehl plus Unterbefehl wie bei git oder zypper:

systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS

Vollständige Anweisungen finden Sie in man 1 systemctl.

Tipp
Tipp: Terminalausgabe und Bash-Vervollständigung

Wenn die Ausgabe an ein Terminal geht (und nicht an eine Pipe oder Datei usw.), senden die systemd-Befehle standardmäßig eine ausführliche Ausgabe an einen Pager. Mit der Option --no-pager deaktivieren Sie den Paging-Modus.

systemd unterstützt außerdem die Bash-Vervollständigung. Hierbei geben Sie die ersten Buchstaben eines Unterbefehls ein und drücken dann →|. Diese Funktion ist nur in der bash-Shell verfügbar und das Paket bash-completion muss installiert sein.

19.2.1 Verwalten von Diensten auf einem laufenden System

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

systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
System V-init
rcMY_SERVICE(S) reload|restart|start|status|stop|...

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 einen einzigen Befehl aus, beispielsweise:

> sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

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

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

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

Tabelle 19.1: Befehle zur Dienstverwaltung

Aufgabe

systemd-Befehl

System V-init-Befehl

Starten. 

start
start

Stoppen. 

stop
stop

Neu starten.  Fährt Dienste herunter und startet sie dann neu. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.

restart
restart

Bedingt neu starten.  Startet Dienste neu, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.

try-restart
try-restart

Neu laden.  Weist die Dienste an, die Konfigurationsdateien neu zu laden ohne die laufenden Vorgänge zu unterbrechen. Anwendungsbeispiel: Weisen Sie Apache an, eine bearbeitete httpd.conf-Konfigurationsdatei neu zu laden. Nicht alle Dienste unterstützen das Neuladen.

reload
reload

Neu laden oder neu starten.  Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet. Wenn ein Dienst noch nicht ausgeführt wird, wird er gestartet.

reload-or-restart
n/a

Bedingt neu laden oder neu starten.  Lädt Dienste neu, wenn das Neuladen unterstützt wird; ansonsten werden die Dienste neu gestartet, wenn sie derzeit ausgeführt werden. Keine Auswirkung bei Diensten, die nicht ausgeführt werden.

reload-or-try-restart
n/a

Ausführliche Statusinformationen abrufen.  Zeigt Informationen zum Dienststatus. Der Befehl systemd zeigt Details wie Beschreibung, ausführbare Datei, Status, cgroup und zuletzt durch den Dienst ausgegebene Meldungen (siehe Abschnitt 19.6.9, „Fehlersuche für Dienste“). Die Detailtiefe bei System V-init ist von Dienst zu Dienst unterschiedlich.

status
status

Kurze Statusinformationen abrufen.  Gibt an, ob Dienste aktiv sind oder nicht.

is-active
status

19.2.2 Dienste dauerhaft aktivieren/deaktivieren

Mit den Dienstverwaltungsbefehlen 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, sodass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Sie können dies mithilfe von YaST oder über die Befehlszeile tun.

19.2.2.1 Aktivieren/Deaktivieren von Diensten über die Befehlszeile

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

Wichtig
Wichtig: Dienststart

Wenn ein Dienst über die Befehlszeile aktiviert wird, wird er nicht automatisch gestartet. Der Dienst wird beim nächsten Systemstart oder bei der nächsten Änderung des Runlevels/Ziels gestartet. Um einen Dienst sofort zu starten, nachdem Sie ihn aktiviert haben, führen Sie systemctl start MY_SERVICE oder rc MY_SERVICE start explizit aus.

Tabelle 19.2: Befehle zum Aktivieren und Deaktivieren von Diensten

Aufgabe

systemd-Befehl

System V-init-Befehl

Aktivieren von. 

systemctl enable MY_SERVICE(S)

insserv MY_SERVICE(S), chkconfig -a MY_SERVICE(S)

Deaktivieren. 

systemctl disable MY_SERVICE(S).service

insserv -r MY_SERVICE(S), chkconfig -d MY_SERVICE(S)

Überprüfen.  Zeigt an, ob ein Dienst aktiviert ist oder nicht.

systemctl is-enabled MY_SERVICE

chkconfig MY_SERVICE

Erneut aktivieren.  Ähnlich wie beim Neustarten eines Diensts, deaktiviert dieser Befehl einen Dienst und aktiviert ihn dann wieder. Nützlich, wenn ein Dienst mit den Standardeinstellungen erneut aktiviert werden soll.

systemctl reenable MY_SERVICE

n/v

Maskierung.  Nach dem Deaktivieren eines Dienstes kann er weiterhin manuell aktiviert werden. Soll ein Dienst deaktiviert werden, maskieren Sie ihn. Mit Vorsicht verwenden.

systemctl mask MY_SERVICE

n/v

Demaskieren.  Ein maskierter Dienst kann erst dann wieder genutzt werden, wenn er demaskiert wurde.

systemctl unmask MY_SERVICE

n/v

19.3 Systemstart und Zielverwaltung

Der gesamte Vorgang des Startens und Herunterfahrens des Systems wird von systemd verwaltet. Von diesem Gesichtspunkt aus kann der Kernel als Hintergrundprozess betrachtet werden, der alle anderen Prozesse verwaltet und die CPU-Zeit sowie den Hardwarezugriff entsprechend den Anforderungen anderer Programme anpasst.

19.3.1 Ziele im Vergleich zu Runlevels

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 nummeriert. 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 dieser Befehl eine hohe Flexibilität.

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

Ausgewählte systemd-Ziel-Units
default.target

Das Ziel, das standardmäßig gebootet wird. Kein reales Ziel, sondern ein symbolischer Link zu einem anderen Ziel wie graphic.target. Kann über YaST dauerhaft geändert werden (siehe Abschnitt 19.4, „Verwalten von Diensten mit YaST“). Soll das Ziel für eine einzige Sitzung geändert werden, geben Sie den Kernel-Parameter systemd.unit=MY_TARGET.target am Bootprompt ein.

emergency.target

Startet eine minimale root-Notfall-Shell an der Konsole. Dieser Befehl darf nur an der Boot-Eingabeaufforderung im Format systemd.unit=emergency.target verwendet werden.

graphical.target

Startet ein System mit Netzwerk, Mehrbenutzerunterstützung und Anzeigemanager.

halt.target

Fährt das System herunter.

mail-transfer-agent.target

Startet alle Dienste, die zum Senden und Empfangen von Mails erforderlich sind.

multi-user.target

Startet ein Mehrbenutzersystem mit Netzwerk.

reboot.target

Bootet das System neu.

rescue.target

Startet ein root-Einzelbenutzersystem ohne Netzwerk. Es stehen grundlegende Werkzeuge für die Systemadministration zur Verfügung. Das rescue-Ziel eignet sich zum Lösen mehrerer Systemprobleme, z. B. zum Beheben fehlerhafter Anmeldungen oder zum Beheben von Problemen mit einem Anzeigetreiber.

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.

Verwenden Sie zum Prüfen des aktuellen Ziels den folgenden Befehl: systemctl get-default

Tabelle 19.3: System V-Runlevels und systemd-Ziel-Units

System V-Runlevel

systemd Ziel

Beschreibung

0

runlevel0.target, halt.target, poweroff.target

System herunterfahren

1, S

runlevel1.target, rescue.target,

Einzelbenutzermodus

2

runlevel2.target, multi-user.target,

Lokaler Mehrbenutzermodus ohne entferntes Netzwerk

3

runlevel3.target, multi-user.target,

Mehrbenutzer-Vollmodus mit Netzwerk

4

runlevel4.target

Nicht verwendet/benutzerdefiniert

5

runlevel5.target, graphical.target,

Mehrbenutzer-Vollmodus mit Netzwerk und Anzeige-Manager

6

runlevel6.target, reboot.target,

Systemneustart

Wichtig
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 19.5.5, „Erstellen von benutzerdefinierten Zielen“.

19.3.1.1 Befehle zum Ändern von Zielen

Mit den folgenden Befehlen arbeiten Sie mit den Ziel-Units:

Aufgabe

systemd-Befehl

System V-init-Befehl

Aktuelles Ziel/Runlevel ändern

systemctl isolate MY_TARGET.Ziel

telinit X

Zum standardmäßigen Ziel/Runlevel wechseln

systemctl default

n/v

Aktuelles Ziel/Runlevel abrufen

systemctl list-units --type=target

Bei systemd sind in der Regel mehrere Ziele aktiv. Mit diesem Befehl werden alle derzeit aktiven Ziele aufgelistet.

who -r

oder

runlevel

Standard-Runlevel dauerhaft ändern

Verwenden Sie die Dienste-Verwaltung, oder führen Sie den folgenden Befehl aus:

ln -sf /usr/lib/systemd/system/ MY_TARGET.target /etc/systemd/system/default.target

Verwenden Sie die Dienste-Verwaltung, oder ändern Sie die Zeile

id: X:initdefault:

in /etc/inittab

Standard-Runlevel für den aktuellen Bootprozess ändern

Geben Sie an der Boot-Eingabeaufforderung die folgende Option ein:

systemd.unit= MY_TARGET.Ziel

Geben Sie an der Boot-Eingabeaufforderung die gewünschte Runlevel-Nummer ein.

Abhängigkeiten für ein Ziel/Runlevel anzeigen

systemctl show -p "Requires" MY_TARGET.Ziel

systemctl show -p "Wants" MY_TARGET.Ziel

Requires (Benötigt) zeigt eine Liste der harten Abhängigkeiten (die in jedem Fall aufgelöst werden müssen), Wants (Erwünscht) dagegen eine Liste der weichen Abhängigkeiten (die nach Möglichkeit aufgelöst werden).

n/v

19.3.2 Fehlersuche beim Systemstart

systemd bietet eine Möglichkeit, den Systemstartvorgang zu analysieren. Sie können die Liste der Dienste 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.

19.3.2.1 Prüfen des Startvorgangs der Dienste

Mit dem Befehl systemctl erzeugen Sie eine Liste aller Dienste, die seit dem Booten des Systems gestartet wurden. Hier werden alle aktiven Dienste wie im nachstehenden (gekürzten) Beispiel aufgeführt. Mit systemctl status MY_SERVICE erhalten Sie weitere Informationen zu einem bestimmten Dienst.

Beispiel 19.1: Liste der aktiven Dienste
# 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'.

Soll die Ausgabe auf Dienste beschränkt werden, die nicht gestartet werden konnten, geben Sie die Option --failed an:

Beispiel 19.2: Liste der fehlerhaften Dienste
# 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

[...]

19.3.2.2 Fehlersuche für die Startzeit

Mit dem Befehl systemd-analyze in systemd führen Sie die Fehlersuche für die Startzeit durch. Hiermit werden der Gesamtzeitaufwand für den Startvorgang sowie eine Liste der beim Starten angeforderten Dienste angezeigt. Auf Wunsch kann auch eine SVG-Grafik erstellt werden, aus der hervorgeht, wie lange der Start der Dienste im Vergleich zu den anderen Diensten dauerte.

Auflisten der Startzeit des Systems
# systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
Auflisten der Startzeit der Dienste
# systemd-analyze blame
    15.000s backup-rpmdb.service
    14.879s mandb.service
     7.646s backup-sysconfig.service
     4.940s postfix.service
     4.921s logrotate.service
     4.640s libvirtd.service
     4.519s display-manager.service
     3.921s btrfsmaintenance-refresh.service
     3.466s lvm2-monitor.service
     2.774s plymouth-quit-wait.service
     2.591s firewalld.service
     2.137s initrd-switch-root.service
     1.954s ModemManager.service
     1.528s rsyslog.service
     1.378s apparmor.service
    [...]
Grafische Darstellung der Startzeit der Dienste
# systemd-analyze plot > jupiter.example.com-startup.svg
Image

19.3.2.3 Prüfen des gesamten Startvorgangs

Die Befehle oben listen die gestarteten Dienste und ihre Startzeiten auf. Eine detailliertere Übersicht erhalten Sie, wenn Sie folgende Parameter an der Boot-Eingabeaufforderung angeben, damit systemd ein ausführliches Protokoll des gesamten Startvorgangs erstellt.

systemd.log_level=debug systemd.log_target=kmsg

systemd schreibt die Protokollmeldungen nunmehr in den Kernel-Ringpuffer. Diesen Puffer zeigen Sie mit dmesg an:

> dmesg -T | less

19.3.3 System V-Kompatibilität

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 Dienst, der durch das init-Skript gestartet wurde, beendet. Als Workaround für diesen Fehler gehen Sie wie folgt vor:

  1. Erstellen Sie einen Service-Datei-Wrapper mit demselben Namen wie das init-Skript und der Dateinamenerweiterung .service:

    [Unit]
    Description=DESCRIPTION
    After=network.target
    
    [Service]
    User=USER
    Type=forking1
    PIDFile=PATH TO PID FILE1
    ExecStart=PATH TO INIT SCRIPT start
    ExecStop=PATH TO INIT SCRIPT stop
    ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1
    
    [Install]
    WantedBy=multi-user.target2

    Ersetzen Sie alle Werte in UPPERCASE LETTERS durch die entsprechenden Werte.

    1

    Optional; nur zu verwenden, wenn mit dem init-Skript ein Daemon gestartet wird.

    2

    multi-user.target startet ebenfalls das init-Skript, wenn Sie in graphical.target booten. Falls der Start nur beim Booten in den Display-Manager erfolgen soll, verwenden Sie graphical.target.

  2. Starten Sie den Daemon mit systemctl start APPLICATION.

19.4 Verwalten von Diensten mit YaST

Grundlegende Aufgaben können auch mit dem YaST-Modul Dienste-Verwaltung ausgeführt werden. Hiermit werden das Starten, Stoppen, Aktivieren und Deaktivieren von Diensten unterstützt. Darüber hinaus können Sie den Status eines Dienstes abrufen und das Standardziel ändern. Starten Sie das YaST-Modul mit YaST › System › Dienste-Verwaltung.

Services Manager
Abbildung 19.1: Services Manager
Ändern des Standard-Systemziels

Zum Ändern des Ziels, in das das System gebootet wird, wählen Sie ein Ziel in der Dropdown-Liste Default System Target aus. Die häufigsten Ziele sind Graphical Interface (Grafische Oberfläche; öffnet einen grafischen Anmeldebildschirm) und Multi-User (Mehrbenutzer; startet das System im Befehlszeilenmodus).

Starten oder Stoppen eines Dienstes

Wählen Sie einen Dienst in der Tabelle aus. Die Spalte Aktiv zeigt, ob er derzeit ausgeführt wird (Aktiv) oder nicht (Inaktiv). Mit Starten bzw. Stoppen schalten Sie den Status um.

Durch das Starten und Stoppen eines Dienstes wird sein Status für die aktuelle Sitzung geändert. Soll der Status beim Neubooten geändert werden, müssen Sie den Dienst aktivieren oder deaktivieren.

Definieren des Verhaltens beim Starten von Diensten

Dienste können entweder automatisch bei Booten oder manuell gestartet werden. Wählen Sie einen Dienst in der Tabelle aus. Die Spalte Start zeigt, ob er derzeit gestartet ist Manuell oder Beim Booten. Mit Startmodus schalten Sie den Status um.

Um den Status eines Dienstes in der aktuellen Sitzung zu ändern, müssen Sie ihn wie oben beschrieben starten oder stoppen.

Anzeigen von Statusmeldungen

Zum Anzeigen der Statusmeldungen für einen Dienst wählen Sie den gewünschten Dienst in der Liste aus und wählen Sie Details anzeigen. Die Ausgabe ist mit der Ausgabe des Befehls systemctl -l und dem Status MY_SERVICE identisch.

19.5 Anpassen systemd

In den folgenden Abschnitten wird beschrieben, wie systemd-Unit-Dateien angepasst werden.

19.5.1 Wo werden Unit-Dateien gespeichert?

Von SUSE bereitgestellte systemd-Unit-Dateien werden in /usr/lib/systemd/ gespeichert. Benutzerdefinierte Unit-Dateien und Drop-Ins von Unit-Dateien werden in /etc/systemd/ gespeichert.

Warnung
Warnung: Verhindern des Überschreibens Ihrer Anpassung

Verwenden Sie beim Anpassen von systemd immer das Verzeichnis /etc/systemd/ anstelle von /usr/lib/systemd/. Ansonsten werden Ihre Änderungen bei der nächsten Aktualisierung von systemd überschrieben.

19.5.2 Überschreiben mit Drop-In-Dateien

Drop-In-Dateien (oder Drop-Ins) sind teilweise Unit-Dateien, die nur bestimmte Einstellungen der Unit-Datei überschreiben. Drop-Ins haben Vorrang vor Hauptkonfigurationsdateien. Der Befehl systemctl edit SERVICE startet den Standardtexteditor und erstellt ein Verzeichnis mit einer leeren override.conf-Datei in /etc/systemd/system/NAME.service.d/. Der Befehl benachrichtigt außerdem den laufenden systemd-Vorgang über die Änderungen.

Um beispielsweise die Zeit zu ändern, die das System auf den Start von MariaDB wartet, führen Sie sudo systemctl edit mariadb.service aus und bearbeiten die geöffnete Datei so, dass nur die geänderten Zeilen eingefügt werden:

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

Passen Sie den Wert TimeoutSec an und speichern Sie die Änderungen. Führen Sie zum Aktivieren der Änderungen sudo systemctl daemon-reload auf.

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

Warnung
Warnung: Erstellen einer Kopie einer vollständigen Unit-Datei

Wenn Sie die Option --full im Befehl systemctl edit --full SERVICE verwenden, wird eine Kopie der ursprünglichen Unit-Datei erstellt, in der Sie bestimmte Optionen ändern können. Eine solche Anpassung wird nicht empfohlen, da bei der Aktualisierung der Unit-Datei durch SUSE ihre Änderungen durch die angepasste Kopie im Verzeichnis /etc/systemd/system/ überschrieben werden. Wenn SUSE Aktualisierungen für Distributions-Drop-Ins bereitstellt, überschreiben sie außerdem die Kopie der Unit-Datei, die mit --full wurde. Um diese Verwirrung zu vermeiden und damit Ihre Anpassung immer gültig bleibt, verwenden Sie Drop-Ins.

19.5.3 Manuelles Erstellen von Drop-in-Dateien

Neben der Verwendung des Befehls systemctl edit können Sie Drop-Ins manuell erstellen, um mehr Kontrolle über ihre Priorität zu haben. Mit solchen Drop-Ins können Sie sowohl Unit- als auch Daemon-Konfigurationsdateien erweitern, ohne die Dateien selbst bearbeiten oder überschreiben zu müssen. Sie werden in den folgenden Verzeichnissen gespeichert:

/etc/systemd/*.conf.d/, /etc/systemd/system/*.service.d/

Drop-Ins, die von Systemadministratoren hinzugefügt und angepasst werden.

/usr/lib/systemd/*.conf.d/, /usr/lib/systemd/system/*.service.d/

Drop-Ins, die von Anpassungspaketen installiert werden, um Upstream-Einstellungen zu überschreiben. SUSE stellt beispielsweise systemd-default-settings bereit.

Tipp
Tipp

Auf der Manpage für man 5 systemd.unit finden Sie die vollständige Liste der Unit-Suchpfade.

Gehen Sie beispielsweise folgendermaßen vor, um die Ratenbegrenzung zu deaktivieren, die durch die Standardeinstellung von systemd-journald erzwungen wird:

  1. Erstellen Sie ein Verzeichnis mit dem Namen /etc/systemd/journald.conf.d.

    > sudo mkdir /etc/systemd/journald.conf.d
    Anmerkung
    Anmerkung

    Der Verzeichnisname muss dem Dienstnamen folgen, den Sie mit der Drop-In-Datei patchen möchten.

  2. Erstellen Sie in diesem Verzeichnis eine Datei mit der Option /etc/systemd/journald.conf.d/60-rate-limit.conf, die Sie überschreiben möchten, z. B.:

    > cat /etc/systemd/journald.conf.d/60-rate-limit.conf
    # Disable rate limiting
    RateLimitIntervalSec=0
  3. Speichern Sie Ihre Änderungen und starten Sie den Dienst des entsprechenden Daemons systemd neu.

    > sudo systemctl restart systemd-journald
Anmerkung
Anmerkung: Vermeiden von Namenskonflikten

Damit Namenskonflikte zwischen Ihren Drop-Ins und von SUSE bereitgestellten Dateien vermieden werden, empfiehlt es sich, allen Drop-Ins eine zweistellige Nummer und einen Bindestrich voranzustellen, z. B. 80-override.conf.

Die folgenden Bereiche sind reserviert:

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

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

  • 30-39 ist für SUSE-Pakete reserviert (außer systemd).

  • 40-49 ist für Pakete von Drittanbietern reserviert.

  • 50 ist für Unit-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-Ins Ihre eigenen Drop-Ins nicht überschreiben können.

Tipp
Tipp

Sie können mit systemctl cat $UNIT auflisten und überprüfen, welche Dateien in der Units-Konfiguration berücksichtigt werden.

Tipp
Tipp

Da die Konfiguration von systemd-Komponenten auf verschiedene Stellen im Dateisystem verstreut sein kann, ist es möglicherweise schwierig, einen Gesamtüberblick zu erhalten. Verwenden Sie die folgenden Befehle, um die Konfiguration einer systemd-Komponente zu prüfen:

  • systemctl cat UNIT_PATTERN druckt Konfigurationsdateien, die sich auf eine oder mehrere systemd-Units beziehen, z. B.:

    > systemctl cat atd.service
  • systemd-analyze cat-config DAEMON_NAME_OR_PATH kopiert den Inhalt einer Konfigurationsdatei und Drop-Ins für einen systemd-Daemon, z. B.:

    > systemd-analyze cat-config systemd/journald.conf

19.5.4 Konvertieren von xinetd-Diensten in systemd

Seit der Version SUSE Linux Enterprise Desktop 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:

# 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:

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

[Install]
WantedBy=sockets.target
# 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 systemd Socket- und Dienst-Dateioptionen finden Sie auf den Handbuchseiten für „systemd.socket“ und „systemd.service“ (man 5 systemd.socket, man 5 systemd.service).

19.5.5 Erstellen von benutzerdefinierten Zielen

Auf SUSE-Systemen mit System V-init wird Runlevel 4 nicht genutzt, sodass 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.

  1. Kopieren Sie die Konfigurationsdatei /usr/lib/systemd/system/graphical.target in /etc/systemd/system/MY_TARGET.target und passen Sie sie entsprechend Ihrer Anforderungen an.

  2. Die im vorangegangenen Schritt kopierte Konfigurationsdatei enthält bereits die erforderlichen (harten) Abhängigkeiten für das Ziel. Um auch die gewünschten (weichen) Abhängigkeiten abzudecken, erstellen Sie das Verzeichnis /etc/systemd/system/MY_TARGET.target.wants.

  3. Erstellen Sie für jeden gewünschten Dienst einen symbolischen Link von /usr/lib/systemd/system nach /etc/systemd/system/MY_TARGET.target.wants.

  4. Sobald Sie alle Einstellungen für das Ziel festgelegt haben, laden Sie die systemd-Konfiguration neu. Damit wird das neue Ziel verfügbar:

    > sudo systemctl daemon-reload

19.6 Erweiterte Nutzung

In den nachfolgenden Abschnitten finden Sie weiterführende Themen für Systemadministratoren. Eine noch eingehendere Dokumentation zu systemd finden Sie in der Serie von Lennart Pöttering zu systemd für Administratoren unter https://0pointer.de/blog/projects/.

19.6.1 Bereinigen von temporären Verzeichnissen

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 – für die Verwaltung temporärer Dateien verantwortlich – liest ihre Konfiguration aus den Dateien /etc/tmpfiles.d/*.conf, /run/tmpfiles.d/*.conf und /usr/lib/tmpfiles.d/*.conf. Die Konfiguration in /etc/tmpfiles.d/*.conf hat Vorrang vor ähnlichen Konfigurationen in den anderen beiden Verzeichnissen. (In /usr/lib/tmpfiles.d/*.conf werden die Konfigurationsdateien der Pakete gespeichert.)

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:

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

19.6.2 Systemprotokoll

In Abschnitt 19.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.

19.6.3 Aufnahmen

Mit dem Unterbefehl 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.

Erstellen eines Snapshots
> sudo systemctl snapshot MY_SNAPSHOT.snapshot
Löschen eines Snapshots
> sudo systemctl delete MY_SNAPSHOT.snapshot
Anzeigen eines Snapshots
> sudo systemctl show MY_SNAPSHOT.snapshot
Aktivieren eines Snapshots
> sudo systemctl isolate MY_SNAPSHOT.snapshot

19.6.4 Laden der Kernelmodule

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 MODULE.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 zu modules-load.d(5).

19.6.5 Ausführen von Aktionen vor dem Laden eines Dienstes

Bei System V mussten init-Aktionen, die vor dem Laden eines Dienstes 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:

Laden der Kernelmodule

Erstellen Sie eine Drop-in-Datei im Verzeichnis /etc/modules-load.d (Syntax siehe man modules-load.d).

Erstellen von Dateien oder Verzeichnissen, Bereinigen von Verzeichnissen, Ändern des Eigentümers

Erstellen Sie eine Drop-in-Datei in /etc/tmpfiles.d (Syntax siehe man tmpfiles.d).

Weitere Aufgaben

Erstellen Sie eine Systemdienstdatei (beispielsweise /etc/systemd/system/before.service) anhand der folgenden Vorlage:

[Unit]
Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=YOUR_COMMAND
# beware, executable is run directly, not through a shell, check the man pages
# systemd.service and systemd.unit for full syntax
[Install]
# target in which to start the service
WantedBy=multi-user.target
#WantedBy=graphical.target

Sobald die Dienstdatei erstellt ist, führen Sie die folgenden Befehle aus (als root):

> sudo systemctl daemon-reload
> sudo systemctl enable before

Bei jedem Bearbeiten der Dienstdatei müssen Sie Folgendes ausführen:

> sudo systemctl daemon-reload

19.6.6 Kernel-Steuergruppen (cgroups)

Auf einem traditionellen System-V-init-System kann ein Prozess nicht immer eindeutig dem Dienst zugeordnet werden, durch den er erzeugt wurde. Bestimmt 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. bestimmte 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. systemd benennt die cgroups dabei nach dem jeweiligen Dienst. 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 Befehl systemd-cgls erhalten Sie eine Liste aller Prozesse, die zu einem Dienst gehören, z. B.:

Beispiel 19.3: Auflisten aller Prozesse, die zu einem Dienst gehören
# 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.

19.6.7 Beenden von Diensten (Senden von Signalen)

Wie in Abschnitt 19.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 Anhalten eines Diensts und seiner untergeordneten Dienste. Untergeordnete Prozesse, die nicht ordnungsgemäß beendet wurden, bleiben als „Zombie-Prozesse“ zurück.

Durch das Konzept von systemd, mit dem jeder Dienst in einer eigenen cgroup abgegrenzt wird, können alle untergeordneten Prozesse eines Diensts erkannt werden, so dass 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.

Senden von SIGTERM an einen Dienst

SIGTERM ist das standardmäßig gesendete Signal.

> sudo systemctl kill MY_SERVICE
Senden von SIGNAL an einen Dienst

Mit der Option -s legen Sie das zu sendende Signal fest.

> sudo systemctl kill -s SIGNAL MY_SERVICE
Auswählen von Prozessen

Standardmäßig sendet der Befehl kill das Signal an alle (all) Prozesse der angegebenen cgroup. Sie können dies jedoch auf den Prozess control oder main beschränken. Damit können Sie beispielsweise das Neuladen der Konfiguration eines Diensts mit dem Signal SIGHUP erzwingen:

> sudo systemctl kill -s SIGHUP --kill-who=main MY_SERVICE

19.6.8 Wichtige Hinweise zum D-Bus-Dienst

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 Anhalten von dbus oder das Neustarten im laufenden System entspricht dem Versuch, PID 1 zu anzuhalten oder neu zu starten. Dadurch wird die Client/Server-Kommunikation von systemd unterbrochen und die meisten systemd-Funktionen werden unbrauchbar.

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.

19.6.9 Fehlersuche für Dienste

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. systemctl status bietet jedoch eine Möglichkeit, den Start und Betrieb eines Diensts zu debuggen.

systemd umfasst einen Protokollierungsmechanismus (Journal), mit dem die Systemmeldungen protokolliert werden. Auf diese Weise können Sie die Dienstmeldungen zusammen mit den Statusmeldungen abrufen. Der Befehl 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.

Anzeigen von Fehlern beim Starten von Diensten

Wenn ein Dienst nicht gestartet wird, erhalten Sie mit systemctl status MY_SERVICE eine ausführliche Fehlermeldung:

# systemctl start apache2
Job failed. See system journal and 'systemctl status' for details.
# systemctl status apache2
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Mon, 04 Apr 2018 16:52:26 +0200; 29s ago
   Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/apache2.service

Apr 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>
Anzeigen der letzten N Dienstmeldungen

Standardmäßig zeigt der Unterbefehl status die letzten zehn Meldungen an, die ein Dienst ausgegeben hat. Mit dem Parameter --lines=N legen Sie eine andere Anzahl von Nachrichten fest:

> sudo systemctl status chronyd
> sudo systemctl --lines=20 status chronyd
Anzeigen von Dienstmeldungen im Anhängemodus

Mit der Option --follow erhalten Sie einen Live-Stream mit Dienstmeldungen; diese Option entspricht tail -f:

> sudo systemctl --follow status chronyd
Ausgabeformat der Meldungen

Mit dem Parameter --output=MODE legen Sie das Ausgabeformat für die Dienstmeldungen fest. Die wichtigsten Modi sind:

short

Das Standardformat. Zeigt die Protokollmeldungen mit einem Zeitstempel in Klartext an.

verbose

Vollständige Ausgabe mit sämtlichen Feldern.

cat

Kurze Ausgabe ohne Zeitstempel.

19.7 systemd-Zeitgeber-Units

Ähnlich wie Cron bieten systemd-Zeitgeber-Units einen Mechanismus für die Planung von Aufträgen unter Linux. Die systemd-Zeitgeber-Units dienen zwar demselben Zweck wie Cron, eröffnen allerdings mehrere Vorteile.

  • Aufträge, die mit einer Zeitgeber-Unit geplant werden, können von anderen systemd-Diensten abhängig sein.

  • Zeitgeber-Units werden wie normale systemd-Dienste behandelt und können daher mit systemctl verwaltet werden.

  • Timer können in Echtzeit und monoton vorliegen.

  • Zeiteinheiten werden im systemd-Journal protokolliert, was die Überwachung und Fehlerbehebung vereinfacht.

systemd-Zeitgeber-Units sind mit der Dateinamenerweiterung .timer gekennzeichnet.

19.7.1 systemd-Zeitgebertypen

Timer-Einheiten können monotone und Echtzeit-Timer verwenden.

  • Ähnlich wie Cronjobs werden Echtzeit-Zeitgeber durch Kalenderereignisse ausgelöst. Echtzeit-Zeitgeber werden mit der Option OnCalendar definiert.

  • Monotone Zeitgeber werden ausgelöst, sobald ein angegebener Zeitraum nach einem bestimmten Startpunkt vergangen ist. Dies ist beispielsweise ein Systemstart-Ereignis oder ein System-Unit-Aktivierungsereignis. Für die Definition von monotonen Zeitgebern stehen mehrere Optionen zur Auswahl, einschließlich OnBootSec, OnUnitActiveSec und OnTypeSec. Monotone Timer sind nicht permanent und werden nach jedem Neustart zurückgesetzt.

19.7.2 systemd-Timer und Dienst-Units

Für jede Zeitgeber-Unit muss eine entsprechende systemd-Unit-Datei vorliegen, die durch die Zeitgeber-Unit gesteuert wird. Anders ausgedruckt aktiviert und verwaltet eine .timer-Datei die entsprechende .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.

19.7.3 Beispiel aus der Praxis

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 dazu eine neue Textdatei zur Bearbeitung und fügen Sie die 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 als Nächstes eine neue Textdatei zur Bearbeitung und fügen Sie die folgende Timer-Definition hinzu:

[Unit]
Description="Run foo shell script"

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

[Install]
WantedBy=multi-user.target

Der Abschnitt [Timer] im Beispiel oben gibt an, welcher Dienst (foo.service) ausgelöst werden soll und wann er 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 Diensts 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: DayOfWeek Year-Month-Day Hour:Minute:Second Im folgenden Beispiel wird ein Dienst täglich um 5:00 Uhr gestartet:

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

Sie können ein Sternchen verwenden, um einen beliebigen Wert anzugeben, und Kommas, um mögliche Werte aufzulisten. Verwenden Sie zwei durch .. getrennte Werte, um einen zusammenhängenden Bereich anzugeben. 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 Beispiel oben wird ein Dienst an Wochentagen um 10 Uhr und am Wochenende um 22 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 Befehl:

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

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

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

19.7.4 Verwalten von systemd-Zeitgebern

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

19.8 Weitere Informationen

Weitere Informationen zu systemd finden Sie in folgenden Online-Quellen:

Startseite

https://systemd.io/

systemd für Administratoren

Lennart Pöttering, einer der systemd-Autoren, hat eine Serie von Blogeinträgen verfasst. (Zum Zeitpunkt, als dieses Kapitel verfasst wurde, standen bereits 13 Einträge zur Verfügung.) Diese sind unter https://0pointer.de/blog/projects/ zu finden.