systemd ist eine Programmsammlung, die Linux-Systeme startet und betreut. systemd ist nach dem Linux Kernel selber die wichtigste Software eines Linuxsystems. Von daher bezeichnet sich das Projekt auf dessen Homepage auch selber als "Sammlung von Grundbausteinen für ein Linux-System.
Die allermeisten Linuxdistributionen wie z.B. Ubuntu, Debian, Raspbery Pi OS, Fedora, Suse usw. setzen systemd ein. systemd ist verantwortlich für das Starten, Verwalten und Überwachen des Bootprozesses sowie des laufenden Systems. systemd wird als allererster Prozess gestartet und hat deshalb die PID 1.
Bei allen Distributionen, die systemd einsetzen, ist es integraler Bestandteil des Systems und muss nicht (nach-) installiert werden.
Wenn man nicht sicher ist, ob die eingesetzte Linuxdistribution systemd nutzt, gibt man folgenden Befehl im Terminal ein:
systemd --versionIst systemd im Einsatz, erhält man aus Ausgabe unter anderem die Versionsnummer der installierten systemd Version.
Eine grundlegende Komponente zum Starten von Programmen und Diensten sowie um Vorzugeben, was systemd wann und wo machen soll, sind Units. Units sind einfache Textdateien, welche aus einer Reihe von Sektionen (in der Regel drei) bestehen. Jede Sektion enthält ein oder mehrere Direktiven. Diese Direktiven teilen systemd mit, was gemacht werden soll.
systemd kennt verschiedene Unit-Typen. Jeder Typ ist für einen bestimmten Zweck gedacht. Units werden anhand der Dateiendung identifiziert. Die Units, mit denen man als normaler Desktopnutzer oder Hobbyadministrator eines Heimservers in Kontakt kommt sind in der Regel nur Service Units und ggf. auch Timer Units. Ersterer dienen dazu, ein Programm oder einen Prozess zu starten (und ggf. zu überwachen), letztere dienen dazu ein Programm / einen Prozess periodisch auszuführen.
Die verschiedenen Unit-Typen sind die folgenden:
.service - eine service Unit. Service Units dienen zum Starten von Prozessen während des Bootvorgangs oder zu einem späteren Zeitpunkt. In Service Units können Abhängigkeiten hinterlegt werden, so dass z.B. Unit B erst starten, wenn Unit A läuft. Außerdem können Units überwachen, ob der darin gestartete Prozess noch läuft und diesen im Falle eines Crashs neu starten.
.timer - eine timer Unit. Timer Units dienen zum periodischen Starten oder Starten zu einem bestimmten Zeitpunkt einer Service Unit. Timer Units übernehmen Aufgaben, die früher mittels cron, at und ähnlichen Tools umgesetzt wurden.
.path - eine path Unit. Path Units dienen zum Überwachen von Verzeichnissen und Dateien. Path Units führen Service Units aus, wenn z.B. im überwachten Verzeichnis eine neue Datei angelegt oder eine bestehende verändert wurde. Im Hintergrund nutzen Path Units inotify.
.mount - eine mount Unit. Mount Units dienen zum Einbinden von Dateisystemen ins System. systemd liest beim Systemstart die Datei /etc/fstab ein und generiert aus den Einträgen dort Mount Units. Von daher hat man die Wahl, Dateisystem dort einzutragen oder direkt eine eigene Mount Unit zu erstellen.
.automount - eine automount Unit. Automount Units dienen zum dynamischen Einbinden von Dateisystemen, d.h. sie werden erst ausgeführt, wenn auf das Dateisystem zugegriffen wird. Für jede Automount Unit muss eine passende Mount Unit existieren. Die Automount Unit überwacht den Zugriff und ruft dann, wen dieser erfolgt, die passenden Mount Unit auf.
.socket - eine socket Unit. Socket Units dienen zum Überwachen von Netzwerk Sockets, FIFO Dateien ("named pipes") und Sockets, die zur Interprozesskommunikaiton eingesetzt werden. Jeder Socket Unit ist eine Service Unit zugeordnet, die ausgeführt wird, wenn Datenverkehr auf dem überwachten Socket eintrifft.
.device - eine device Unit. Device Units dienen zum Überwachen von "devices", also von Geräten. Dazu gehören alle Geräte, die unter Sysfs gelistet sind bzw. von udev eingebunden werden.
.swap - eine swap Unit. Eine Swap Unit dient zum Verwalten einer Swap Partition bzw. einer Swap Datei.
.target - eine target Unit. Target Units definieren Zielpunkte, die im laufenden System erreicht werden. Ein Beispiel ist z.B. das "network-online.target", dass beim Bootvorgang erreicht wird, sobald die Netzwerkschnittstellen des Linux-Kernels zur Verfügung stehen und eine Netzwerkverbindung haben. Ein weiteres Beispiel ist das "multi-user.target", das erreicht ist, sobald sich mehrere Nutzer im System anmelden könnten. Service Units können in Abhängigkeit des Erreichens einer Target Unit gestartet werden (z.B. das man eine Serveranwendung erst startet, wenn das Netzwerk verfügbar ist). Außerdem können Target Units Service Units hinzugefügt werden, so dass diese geladen und ausgeführt werden, wenn systemd die Aufgaben zum Erreichen eines Targets abarbeitet.
.slice - eine slice Unit. Slice Units dienen zum Verwalten von Ressourcen für eine Gruppe von Prozessen. Im Hintergrund nutzt systemd dafür Linux Control Groups (kurz: cgroups).
.scope - eine scope Unit. Scope Units dienen zum Bündeln und Gruppieren von Arbeitsprozessen des Systems. scope Units werden dynamisch seitens systemd angelegt und nicht über selbst angelegte .scope-Dateien.
systemd unterscheidet zwischen systemweiten und User Units (auf deutsch: nutzerspezifische Units). systemweite Units gelten, wie der Name schon sagt, für das gesamte System und werden in der Regel bereits beim Booten des Systems gestartet und angelegt. Dies erfolgt unabhängig davon, ob eine oder auch mehrere Nutzer am System angemeldet sind. systemweit Units können nur mit Root-Rechten angelegt bzw. editiert werden. Systemweite Units müssen aber nicht zwingend mit Root-Rechten laufen, sie können auch anderen Nutzern des Systems zugewiesen werden.
User Units werden ausgeführt, wenn sich der Nutzer ins System. User Units könnten von jedem Nutzer individuell für sich selber angelegt werden. Als Administrator kann man aber auch User Units für alle Nutzer anlegen. Diese werden immer dann gestartet, wenn es ein (egal welcher) Nutzer am System anmeldet.
User Units werden - sofern nicht explizit anders hinterlegt - wieder gestoppt, wenn sich der Benutzer wieder vom System abmeldet.
Unter Ubuntu, Debian und Raspberry Pi OS sind systemweite Unit-Dateien normalerweise in einer der folgenden Verzeichnisse gespeichert:
/lib/systemd/system: Units, die Teil der Installation sind oder von nachinstallierten Paketen mitgebracht werden, liegen hier. Diese Unit-Dateien sollten normalerweise nicht vom Administrator oder einem Nutzer editiert werden.
/etc/systemd/system: Hier werden Unit-Dateien abgelegt, die vom Administrator für das System angelegt werden.
User Units werden werden normalerweise in einem der folgenden vier Verzeichnisse gespeichert:
/usr/lib/systemd/user: Verzeichnis für User Units, die Teil der Standardinstallation des Systems sind.
/etc/systemd/user: Hier werde Unit-Dateien vom Administrator gespeichert, die für alle Nutzer des System gelten.
~/.local/share/systemd/user: Wenn die Installation eines Pakets speziell für diesen Nutzerin User Unit-Dateien mitbringen, werden sie in diesem Verzeichnis abgelegt.
~/.config/systemd/user: Hier kann der Nutzer eigene User-Dateien anlegen.
systemctl ist das zentrale Werkzeug zur Interaktion mit systemd. Mit systemctl kann man z.B. den Status von Units überprüfen sowie diese Starten, Stoppen, Deaktiveren etc. Außerdem kann mit systemctldas System heruntergefahren, neu gestartet und schlafen gelegt werden.
systemd bringt zum Logging journald mit. Ebenso wie systemd ist journald Teil der Standardinstallation von Ubuntu, Debian, Raspberry Pi OS, Fedora , Suse usw. Alle Aktionen, Fehler etc. werden in das zentrale Journal geloggt.
Das Journal kann mit Hilfe von journalctl abgefragt werden.
systemd bringt eine Reihe weiterer Werkzeuge mit. Einige davon sind:
systemd-analyze: Werkzeug zur Visualisierung des Boot-Vorgangs sowie der Anzeige, welche Unit beim Systemstart wie viel Zeit in Anspruch nimmt.
systemd-inhibit: Werkzeug mit dem man Einstellen kann, dass das System nicht heruntergefahren werden kann, wenn bestimmt Units / Prozesse noch laufen.
systemd-path: zeigt an, welche Verzeichnisse für was genutzt werden.