Systemd/Grundlagen: Unterschied zwischen den Versionen
Die Seite wurde neu angelegt: „== Grundlagen == Aktuelle Versionen von Fedora, OpenSuse, Mandriva und einigen anderen Distributionen starten das System bereits mit Systemd * Das Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit und erfordert andere Kniffe als Sysvinit, wenn es Probleme gibt ; Sysvinit- und Upstart Einige von Sysvinit- und Upstart-Distributionen gewohnte Kommandos und Tricks arbeiten durch Kompatibilitätsmaßnahmen auch unter Systemd Um die Fähig…“ |
K Textersetzung - „–“ durch „-“ |
||
| (10 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
== Grundlagen == | === Grundlagen === | ||
Viele aktuelle Distributionen starten das System mit Systemd | |||
* Das Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit | * Das Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit | ||
* Erfordert andere Kniffe als Sysvinit, wenn es Probleme gibt | |||
; Sysvinit- und Upstart | ; Sysvinit- und Upstart | ||
| Zeile 7: | Zeile 8: | ||
Um die Fähigkeiten von Systemd richtig zu nutzen, sollte der Administrator allerdings auch Werkzeuge und Parameter von Systemd kennen | Um die Fähigkeiten von Systemd richtig zu nutzen, sollte der Administrator allerdings auch Werkzeuge und Parameter von Systemd kennen | ||
=== systemctl === | |||
Wichtigstes Tool zur Interaktion mit Systemd ist das Kommandozeilenprogramm systemctl | Wichtigstes Tool zur Interaktion mit Systemd ist das Kommandozeilenprogramm systemctl | ||
* Für Änderungen an der Konfiguration oder den Neustart von Hintergrunddiensten erfordert es Root-Rechte; einige Diagnose-Aufrufe dürfen auch einfache Anwender ausführen | * Für Änderungen an der Konfiguration oder den Neustart von Hintergrunddiensten erfordert es Root-Rechte; einige Diagnose-Aufrufe dürfen auch einfache Anwender ausführen | ||
| Zeile 15: | Zeile 16: | ||
* Dazu gehört neben dem Einbinden und Prüfen von Datenträgern auch das Starten von Hintergrunddiensten oder das Einrichten von Hardware | * Dazu gehört neben dem Einbinden und Prüfen von Datenträgern auch das Starten von Hintergrunddiensten oder das Einrichten von Hardware | ||
Bei einer Standardinstallation von Fedora | Bei einer Standardinstallation von Fedora listet Systemctl rund hundertsechzig aktive Units in zehn verschiedenen Spielarten | ||
* Zu den wichtigsten zählen Service-Units | * Zu den wichtigsten zählen Service-Units | ||
* Sie kümmern sich um Hintergrunddienste, die eine Sysvinit-Distribution typischerweise über Init-Skripte startet | * Sie kümmern sich um Hintergrunddienste, die eine Sysvinit-Distribution typischerweise über Init-Skripte startet | ||
* Mount- und Automount-Units binden Dateisysteme ein | * Mount- und Automount-Units binden Dateisysteme ein | ||
=== Socket-Units === | |||
Socket-Units legen Sockets an; sie starten indirekt über Abhängigkeiten einen andere Unit, sobald auf den Socket zugegriffen wird. (Eine detaillierte Erläuterung des Unit-Konzepts finden Sie im ersten Teil des Artikels.) | Socket-Units legen Sockets an; sie starten indirekt über Abhängigkeiten einen andere Unit, sobald auf den Socket zugegriffen wird. (Eine detaillierte Erläuterung des Unit-Konzepts finden Sie im ersten Teil des Artikels.) | ||
Über einen Parameter kann man Systemctl anweisen, nur Units eines bestimmten Typs aufzulisten, etwa alle Service-Units | Über einen Parameter kann man Systemctl anweisen, nur Units eines bestimmten Typs aufzulisten, etwa alle Service-Units | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
systemctl --type=service | |||
</syntaxhighlight> | |||
Systemctl leitet seine Ausgabe automatisch an less weiter; über die Pfeiltasten lässt sich nicht nur hoch- und runterscrollen, sondern auch nach rechts, denn dort verbergen sich manchmal weitere Informationen | Systemctl leitet seine Ausgabe automatisch an less weiter; über die Pfeiltasten lässt sich nicht nur hoch- und runterscrollen, sondern auch nach rechts, denn dort verbergen sich manchmal weitere Informationen | ||
| Zeile 30: | Zeile 33: | ||
In der ersten Spalte der Ausgabe findet sich der Unit-Name | In der ersten Spalte der Ausgabe findet sich der Unit-Name | ||
* Die zweite Spalte gibt an, ob Systemd die Unit-Definition laden konnte, die dritte, ob die Unit aktiv ist | * Die zweite Spalte gibt an, ob Systemd die Unit-Definition laden konnte, die dritte, ob die Unit aktiv ist | ||
* Inaktive | * Inaktive - installierte, aber nicht zum Start vorgesehene - Units gibt das Programm nur mit dem Schalter <tt>-a</tt> aus; dasselbe gilt für Units, die das Init-System etwa aufgrund eines Fehlers in der Unit-Datei nicht laden konnte | ||
Spalte vier liefert den aktuellen Status. "exited" zeigt an, dass sich der Prozess ohne Fehler beendet hat | Spalte vier liefert den aktuellen Status. "exited" zeigt an, dass sich der Prozess ohne Fehler beendet hat | ||
* Das ist zum Beispiel bei Diensten der Fall, die im Hintergrund weiterlaufen | * Das ist zum Beispiel bei Diensten der Fall, die im Hintergrund weiterlaufen - etwa bei der Service-Unit, die aus Kompatibilitätsgründen die von Sysvinit bekannte Datei /etc/rc.local beim Systemstart ausführt. "running" steht bei Diensten, die im Hintergrund laufen: cron, dbus, sshd, udev und andere | ||
In der fünften Spalte folgt eine Beschreibung der Unit | In der fünften Spalte folgt eine Beschreibung der Unit | ||
* Wenn sie mit "LSB" oder "SYSV" beginnt, hat Systemd die Unit automatisch erzeugt, um ein traditionelles Init-Skript abzuarbeiten | * Wenn sie mit "LSB" oder "SYSV" beginnt, hat Systemd die Unit automatisch erzeugt, um ein traditionelles Init-Skript abzuarbeiten | ||
Bei Diensten, die nicht gestartet werden konnten oder später abgestürzt sind, steht in der vierten Spalte "failed" | Bei Diensten, die nicht gestartet werden konnten oder später abgestürzt sind, steht in der vierten Spalte "failed" - rot hervorgehoben, sofern die Konsole farbige Ausgabe beherrscht | ||
Das <tt>status</tt>-Kommando von sytemctl gibt den Zeitpunkt des Abbruchs und den zurückgelieferten Fehlercode des Programms aus, beispielsweise | Das <tt>status</tt>-Kommando von sytemctl gibt den Zeitpunkt des Abbruchs und den zurückgelieferten Fehlercode des Programms aus, beispielsweise | ||
<syntaxhighlight lang="bash" highlight="1" line copy> | |||
systemctl status NetworkManager.service | |||
</syntaxhighlight> | |||
Bei einem frisch installierten Fedora | Bei einem frisch installierten Fedora listet Systemctl um die 60 Service-Units auf | ||
* Darunter sind auch die Login-Prozesse für die Textkonsolen (agetty), denn anders als Sysvinit handhabt Systemd diese über Service-Units wie einen normalen Hintergrunddienst | * Darunter sind auch die Login-Prozesse für die Textkonsolen (agetty), denn anders als Sysvinit handhabt Systemd diese über Service-Units wie einen normalen Hintergrunddienst | ||
| Zeile 85: | Zeile 90: | ||
systemctl isolate rescue.target | systemctl isolate rescue.target | ||
Der Wechsel in das Rescue-Target ist für Administrationsaufgaben interessant, denn dabei beendet Systemd alle User-Logins und Hintergrunddienste, sodass nur noch Systemdienste laufen | Der Wechsel in das Rescue-Target ist für Administrationsaufgaben interessant, denn dabei beendet Systemd alle User-Logins und Hintergrunddienste, sodass nur noch Systemdienste laufen - etwa jene zur Überwachung von Logical Volumes (lvm2-monitor) | ||
Manchmal müssen auch diese für Umbauten heruntergefahren werden, was mit dem Notfall-Modus <tt>emergency.target</tt> gelingt; hier laufen nur noch die Kernel-Threads | Manchmal müssen auch diese für Umbauten heruntergefahren werden, was mit dem Notfall-Modus <tt>emergency.target</tt> gelingt; hier laufen nur noch die Kernel-Threads | ||
| Zeile 94: | Zeile 99: | ||
systemctl show -p Wants multi-user.target | systemctl show -p Wants multi-user.target | ||
In der Ausgabe können sich andere Targets finden | In der Ausgabe können sich andere Targets finden - beim multi-user.target etwa <tt>basic.target</tt> | ||
* Das wiederum hängt vom <tt>sysinit.target</tt> ab, das <tt>local-fs.target</tt> voraussetzt | * Das wiederum hängt vom <tt>sysinit.target</tt> ab, das <tt>local-fs.target</tt> voraussetzt | ||
| Zeile 142: | Zeile 147: | ||
systemctl kexec | systemctl kexec | ||
Nach dem Stoppen aller Dienste weist Systemd den laufenden Kernel an, einen zuvor konfigurierten Linux-Kernel direkt zu starten | Nach dem Stoppen aller Dienste weist Systemd den laufenden Kernel an, einen zuvor konfigurierten Linux-Kernel direkt zu starten - ohne BIOS-Selbsttest und Boot-Loader | ||
* Ist kein Kexec-Kernel konfiguriert, erfolgt ein normaler Neustart | * Ist kein Kexec-Kernel konfiguriert, erfolgt ein normaler Neustart | ||
| Zeile 156: | Zeile 161: | ||
=== Fehleranalyse === | === Fehleranalyse === | ||
* [[Systemd/Fehleranalyse]] | |||
* | |||
=== Dienste konfigurieren === | === Dienste konfigurieren === | ||
* [[Systemd/Dienste]] | |||
[[Kategorie:Systemd]] | |||
* | |||
Aktuelle Version vom 11. Mai 2025, 20:58 Uhr
Grundlagen
Viele aktuelle Distributionen starten das System mit Systemd
- Das Init-System bringt eigene Werkzeuge zur Konfiguration und Diagnose mit
- Erfordert andere Kniffe als Sysvinit, wenn es Probleme gibt
- Sysvinit- und Upstart
Einige von Sysvinit- und Upstart-Distributionen gewohnte Kommandos und Tricks arbeiten durch Kompatibilitätsmaßnahmen auch unter Systemd Um die Fähigkeiten von Systemd richtig zu nutzen, sollte der Administrator allerdings auch Werkzeuge und Parameter von Systemd kennen
systemctl
Wichtigstes Tool zur Interaktion mit Systemd ist das Kommandozeilenprogramm systemctl
- Für Änderungen an der Konfiguration oder den Neustart von Hintergrunddiensten erfordert es Root-Rechte; einige Diagnose-Aufrufe dürfen auch einfache Anwender ausführen
- Aufruf
Wer das Programm ohne jegliche Parameter aufruft, erhält eine Liste der "Units", die beim Systemstart anfallende Aufgaben erledigen
- Dazu gehört neben dem Einbinden und Prüfen von Datenträgern auch das Starten von Hintergrunddiensten oder das Einrichten von Hardware
Bei einer Standardinstallation von Fedora listet Systemctl rund hundertsechzig aktive Units in zehn verschiedenen Spielarten
- Zu den wichtigsten zählen Service-Units
- Sie kümmern sich um Hintergrunddienste, die eine Sysvinit-Distribution typischerweise über Init-Skripte startet
- Mount- und Automount-Units binden Dateisysteme ein
Socket-Units
Socket-Units legen Sockets an; sie starten indirekt über Abhängigkeiten einen andere Unit, sobald auf den Socket zugegriffen wird. (Eine detaillierte Erläuterung des Unit-Konzepts finden Sie im ersten Teil des Artikels.)
Über einen Parameter kann man Systemctl anweisen, nur Units eines bestimmten Typs aufzulisten, etwa alle Service-Units
systemctl --type=service
Systemctl leitet seine Ausgabe automatisch an less weiter; über die Pfeiltasten lässt sich nicht nur hoch- und runterscrollen, sondern auch nach rechts, denn dort verbergen sich manchmal weitere Informationen
In der ersten Spalte der Ausgabe findet sich der Unit-Name
- Die zweite Spalte gibt an, ob Systemd die Unit-Definition laden konnte, die dritte, ob die Unit aktiv ist
- Inaktive - installierte, aber nicht zum Start vorgesehene - Units gibt das Programm nur mit dem Schalter -a aus; dasselbe gilt für Units, die das Init-System etwa aufgrund eines Fehlers in der Unit-Datei nicht laden konnte
Spalte vier liefert den aktuellen Status. "exited" zeigt an, dass sich der Prozess ohne Fehler beendet hat
- Das ist zum Beispiel bei Diensten der Fall, die im Hintergrund weiterlaufen - etwa bei der Service-Unit, die aus Kompatibilitätsgründen die von Sysvinit bekannte Datei /etc/rc.local beim Systemstart ausführt. "running" steht bei Diensten, die im Hintergrund laufen: cron, dbus, sshd, udev und andere
In der fünften Spalte folgt eine Beschreibung der Unit
- Wenn sie mit "LSB" oder "SYSV" beginnt, hat Systemd die Unit automatisch erzeugt, um ein traditionelles Init-Skript abzuarbeiten
Bei Diensten, die nicht gestartet werden konnten oder später abgestürzt sind, steht in der vierten Spalte "failed" - rot hervorgehoben, sofern die Konsole farbige Ausgabe beherrscht
Das status-Kommando von sytemctl gibt den Zeitpunkt des Abbruchs und den zurückgelieferten Fehlercode des Programms aus, beispielsweise
systemctl status NetworkManager.service
Bei einem frisch installierten Fedora listet Systemctl um die 60 Service-Units auf
- Darunter sind auch die Login-Prozesse für die Textkonsolen (agetty), denn anders als Sysvinit handhabt Systemd diese über Service-Units wie einen normalen Hintergrunddienst
Units
Die Konfigurationsdateien zum Erzeugen der Units, die Systemd mitbringt, liegen in /lib/systemd/system/; eine gleichnamige Datei in /etc/systemd/system/ hat jedoch Vorrang
Unit-Definition sind meist deutlich kürzer als die klassischen Sys-V-Init-Skripte
- Eine Unit-Datei für den Dienst zur Netzwerkzeit-Synchronisierung via NTP ist nur wenige Zeilen lang:
[Unit] Description=Network Time Service [Service] ExecStart=/usr/bin/ntpd -n -u ntp:ntp -g [Install] WantedBy=multi-user.target
Alle Unit-Dateien enthalten einen durch [Unit] eingeleiteten Abschnitt mit allgemeinen Einstellungen, darunter eine kurze Beschreibung
- Im Abschnitt [Service] folgen dienstspezifische Angaben; bei NTP ist das lediglich das Kommando, um den Dienst zu starten
- Falls ein spezieller Befehl zum Beenden nötig ist, kann man diesen über eine ExecStop-Anweisung festlegen
Beim NTP-Daemon ist das unnötig, weil er sich in guter Unix-Tradition durch ein SIGTERM-Signal beenden lässt; das sendet Systemd zum Beenden, wenn kein anderer Befehl spezifiziert ist
Der Abschnitt [Install] enthält Anweisungen, die Systemd bei der (De-)Installation interpretiert; der Eintrag im NTP-Beispiel bedeutet, dass die Zeitsynchronisation beim Ansteuern des Targets "Multi-User" aufgerufen werden soll
Targets
Die Targets-Units bieten ein Konzept, das den Runlevels von Sysvinit ähnelt; aus Kompatibilitätsgründen versteht Systemd sogar die Runlevel-Namen zur Ansteuerung äquivalenter Targets
Wie gewohnt kann man daher bei Fedora 16 dem Kernel im Boot-Loader den Parameter single mitgeben; Systemd steuert daraufhin rescue.target an, das eine minimale, dem Single-User-Modus entsprechende Umgebung bietet
Auch 3 funktioniert, um den Multi-User-Modus ohne grafischen Anmeldemanager anzusteuern
- Repräsentiert wird dieser Modus in Systemd durch die Target-Unit multi-user
- Um multi-user.target zum Standard zu machen, reicht ein Links:
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
Soll der grafische Anmeldemanager später doch wieder standardmäßig starten, kann man auf die gleiche Weise graphical.target zum Standardziel erheben; es ist das Äquivalent zum Runlevel 5 von Fedora und OpenSuse
Alternativ zu den alten Runlevel-Bezeichnungen kann man dem Kernel auch die Namen der zu startenden Target-Unit mitgeben:
systemd.unit=multi-user.target
Um im Betrieb eine andere Target-Unit anzusteuern, dient das isolate-Kommando von Systemctl:
systemctl isolate rescue.target
Der Wechsel in das Rescue-Target ist für Administrationsaufgaben interessant, denn dabei beendet Systemd alle User-Logins und Hintergrunddienste, sodass nur noch Systemdienste laufen - etwa jene zur Überwachung von Logical Volumes (lvm2-monitor)
Manchmal müssen auch diese für Umbauten heruntergefahren werden, was mit dem Notfall-Modus emergency.target gelingt; hier laufen nur noch die Kernel-Threads
Verlangen
Das show-Kommando von Systemctl liefert einige Interna zu den laufenden Units und den über sie ausgeführten Arbeiten
- Mit ihm lässt sich auch ausgeben, welche Units Systemd beim Ansteuern des Multi-User-Targets aufruft:
systemctl show -p Wants multi-user.target
In der Ausgabe können sich andere Targets finden - beim multi-user.target etwa basic.target
- Das wiederum hängt vom sysinit.target ab, das local-fs.target voraussetzt
Diese drei Targets kümmern sich um die Grundeinrichtung des Systems; dazu zählen das Einbinden der Dateisysteme und der Start von Udev
- Zum Spezifizieren der Abhängigkeit vom Basic-Target enthält die Unit-Konfigurationsdatei multi-user.target folgende Angaben:
Requires=basic.target After=basic.target
Durch die After-Angabe erfährt Systemd, dass es das Target nicht nur aufrufen, sondern auch den seinen vollständigen Start abwarten muss
- Neben Requires gibt es auch noch das schwächere Wants
Darüber angegebene Units ruft Systemd ebenfalls auf, setzt den Start aber auch fort, wenn eine von ihnen nicht startet
Diese Art der Abhängigkeit lässt sich auch über Links zu Unit-Dateien spezifizieren, die in einem Verzeichnis angelegt werden, dessen Name sich aus dem Namen der target-Unit und angehängtem .wants zusammensetzen, etwa
.../systemd/system/multi-user.target.wants/
Deaktivieren
Wer die NTPD-Service-Unit deaktivieren will, damit die Systemzeit beim Booten nicht via NTP synchronisiert wird, kann das folgenden Befehl tun:
systemctl disable ntpd.service
Dabei macht Systemctl nichts anderes, als den Link auf die Service-Unit-Datei in den Wants-Verzeichnissen zu entfernen; beim Aktivieren eines Dienstes mit enable erstellt das Tool einen Link
- Beides kann man auch manuell tun, um Units zu (de)aktiviern
Wird ein Dienst nicht von einer Unit, sondern über ein traditionelles Init-Skript gestartet, leitet Systemctl die Aufforderung zum Aktivieren an das Programm chkconfig weiter
- Bei Fedora ist das etwa der Fall, wenn man Apache installiert und via Systemctl aktiviert
Das (De)Aktivieren eines Dienstes wirkt sich erst beim nächsten Start oder Beenden des Systems aus
- Folgendes Kommando startet einen Dienst einmalig sofort:
systemctl start ntpd.service
Der Parameter stop beendet den Dienst
- Mit dem Kommando status liefert Systemctl Information über die Unit, darunter ihren derzeitigen Zustand und den Namen der sie spezifizierenden Datei
- Zudem gibt das Programm aus, ob und wie lange der Dienst bereits läuft und welche Prozesse zu ihm gehören; den Hauptprozess weist Systemctl dabei explizit aus
Über die Zugehörigkeit zu den von Systemd angelegten Control Groups lässt sich recht einfach herausfinden, welche Prozesse von welchem Dienst gestartet wurden
- Die von Systemd angelegte Cgroup-Hierarchie gibt der Befehl systemd-cgls aus; alternativ zeigt ps die Gruppenzugehörigkeit an:
ps xaw -eo pid,args,cgroup
Systemstart Probleme
Falls beim Systemstart Probleme auftreten, an denen Systemd direkt oder indirekt beteiligt scheint, sollten Sie dem Kernel die folgenden Parameter im Boot-Loader mitgeben:
systemd.log_target=kmsg systemd.log_level=debug
Systemd schreibt dann ausführliche Informationen zur Fehlersuche auf die Konsole und in den Puffer der Kernel-Meldungen, den man später mit dmesg auslesen kann
Zu Systemd gehören die Kommandozeilenprogramme poweroff, halt und reboot; alternativ kann man das System über die gleichlautenden Systemctl-Kommandos herunterfahren oder neu starten
- Einen Neustart erreicht man auch mit dem Kommando
systemctl kexec
Nach dem Stoppen aller Dienste weist Systemd den laufenden Kernel an, einen zuvor konfigurierten Linux-Kernel direkt zu starten - ohne BIOS-Selbsttest und Boot-Loader
- Ist kein Kexec-Kernel konfiguriert, erfolgt ein normaler Neustart
Administrationsaufgaben
Bei gängigen Administrationsaufgaben kommt man nur mit den Service- und Target-Units direkt in Kontakt; die anderen Units sind vor allem für spezielle Funktionen von Systemd wichtig oder erledigen beim Systemstart all jene Dinge, um die sich bei Sysvinit- und Upstart-Distributionen distributionsspezifische Skripte gekümmert haben
Dazu gehört etwa das Einbinden der in /etc/fstab spezifizierten Dateisysteme, das Aktivieren von Auslagerungsspeicher oder das gelegentliche Aufräumen des /tmp-Verzeichnisses
Für einige dieser Arbeiten bringt Systemd eine Automount-Funktion mit, die Pseudo-Einhängepunkte für in /etc/fstab konfigurierte Dateisysteme anlegen kann; tatsächlich eingebunden werden sie allerdings erst beim ersten Zugriff
Das Hinzufügen von "comment=systemd.automount" in /etc/fstab verwandelt einen beliebigen Mount-Punkt in einen Automount-Punkt
- Das kann den Startvorgang beschleunigen und ist beispielsweise für Netzwerkfreigaben nützlich, wenn die Netzverbindung über den NetworkManager erst beim Einloggen eines Users aufgebaut wird