Anmerkung:
Die folgende, allgemeine Einführung zu systemd wurde überwiegend der
ins deutsche
übersetzten Manpage entnommen. Der Dank geht an Helge
Kreutzmann.
systemd ist ein System- und Diensteverwalter, der
beim Systemstart als erster Prozess (als PID 1) ausgeführt wird und
somit als Init-System agiert, das System hochfährt und
auf Anwendungsebene Dienste verwaltet.
Entwickelt wird es federführend von den Red Hat Entwicklern Lennart
Poettering und Kay Sievers.
In Debian wurde die Einführung des systemd als Standard-Init-System lange, kontrovers und emotional diskutiert bis im Februar 2014 der Technische Ausschuss für systemd stimmte.
Seit der Veröffentlichung von 2013.2 “December” benutzt siduction bereits systemd als Standard-Init-System.
Systemd stellt ein Abhängigkeitssystem zwischen verschiedenen
Einheiten namens “Units” in 11 verschiedenen Typen (siehe
unten) bereit. Units kapseln verschiedene Objekte, die für den
Systemstart und -betrieb relevant sind.
Units können “aktiv” oder “inaktiv”, sowie im Prozess
der “Aktivierung” oder “Deaktivierung”, d.h. zwischen
den zwei erstgenannten Zuständen sein. Ein besonderer Zustand
“fehlgeschlagen” ist auch verfügbar, der sehr ähnlich zu
inaktiv ist. Falls dieser Zustand erreicht wird, wird die Ursache für
spätere Einsichtnahme protokolliert. Siehe die Handbuchseite Sytemd-Journal.
Mit systemd können viele Prozesse parallel gesteuert werden, da die
Unit-Dateien mögliche Abhängigkeiten deklarieren und systemd
erforderliche Abhängigkeiten automatisch hinzugefügt.
Die von systemd verwalteten Units werden mittels Unit-Dateien
konfiguriert.
Die Unit-Dateien sind in verschiedene Sektionen unterteilte, reine
Textdateien im INI-Format. Dadurch ist ihr Inhalt ohne Kenntnis einer
Scriptsprache leicht verständlich und editierbar. Alle Unit-Dateien
müssen eine Sektion entsprechend des Unit Typs haben und können die
generischen Sektionen [Unit] und [Install] enthalten.
Die Handbuchseite Systemd
Unit-Datei erläutert den grundlegenden Aufbau der Unit-Dateien,
sowie viele Optionen der generischen Sektionen [Unit] und [Install].
Bevor wir uns den Unit-Typen zuwenden, ist es ratsam die
Handbuchseite Systemd
Unit-Datei zu lesen, um die Wirkungsweise der generischen Sektionen
und ihrer Optionen zu verstehen.
Die folgenden Unit-Typen sind verfügbar, und sofern verlinkt, führt der
Link zu einer ausführlicheren Beschreibung in unserem Handbuch:
Dienste-Units (systemd.service), die Daemons und die Prozesse, aus denen sie bestehen, starten und steuern.
Socket-Units (systemd.socket), die lokale IPC- oder Netzwerk-Sockets im System kapseln, nützlich für Socket-basierte Aktivierung.
Target-Units (systemd.target) sind für die Gruppierung von Units nützlich. Sie stellen während des Systemstarts auch als Runlevel bekannte Synchronisationspunkte zur Verfügung.
Geräte-Units (systemd.device) legen Kernel-Geräte (alle Block- und Netzwerkgeräte) in systemd offen und können zur Implementierung Geräte-basierter Aktivierung verwandt werden.
Mount-Units (systemd.mount) steuern Einhängepunkte im Dateisystem.
Automount-Units (systemd.automount) stellen Fähigkeiten zum Selbsteinhängen bereit, für bedarfsgesteuertes Einhängen von Dateisystemen sowie parallelisiertem Systemstart.
Zeitgeber-Units (systemd.timer) sind für das Auslösen der Aktivierung von anderen Units basierend auf Zeitgebern nützlich.
Auslagerungs-Units (systemd.swap) sind ähnlich zu Einhänge-Units und kapseln Speicherauslagerungs-Partitionen oder -Dateien des Betriebssystems.
Pfad-Units (systemd.path) können zur Aktivierung andere Dienste, wenn sich Dateisystemobjekte ändern oder verändert werden, verwandt werden.
Slice-Units (systemd.slice) können zur Gruppierung von Units, die Systemprozesse (wie Dienste- und Bereichs-Units) in einem hierarchischen Baum aus Ressourcenverwaltungsgründen verwalten, verwandt werden.
Scope-Units (systemd.scope) sind ähnlich zu Dienste-Units, verwalten aber fremde Prozesse, statt sie auch zu starten.
Die Unit-Dateien, die durch den Paketverwalter der Distribution
installiert wurden, befinden sich im Verzeichnis
/lib/systemd/system/. Selbst erstellte Unit-Dateien legen
wir im Verzeichnis /usr/local/lib/systemd/system/ ab. (Ggf.
ist das Verzeichnis zuvor mit dem Befehl
mkdir -p /usr/local/lib/systemd/system/
anzulegen.)
Die Steuerung des Status (enabled, disabled) einer Unit erfolgt über
Symlink im Verzeichnis /etc/systemd/system/.
Das Verzeichnis /run/systemd/system/ beinhaltet zur
Laufzeit erstellte Unit-Dateien.
Systemd bietet noch weitere Funktionen. Eine davon ist logind als Ersatz für das nicht mehr weiter gepflegte ConsoleKit . Damit steuert systemd Sitzungen und Energiemanagement. Nicht zuletzt bietet systemd eine Menge an weiteren Möglichkeiten wie beispielsweise das Aufspannen eines Containers (ähnlich einer Chroot) mittels systemd-nspawn und viele weitere. Ein Blick in die Linkliste auf Freedesktop ermöglicht weitere Entdeckungen, unter anderem auch die ausführliche Dokumentation von Hauptentwickler Lennart Poettering zu systemd.
Einer der Jobs von systemd ist es Dienste zu starten, zu stoppen oder
sonst wie zu steuern. Dazu dient der Befehl systemctl.
Die beiden folgenden Befehle integrieren bzw. entfernen die Unit anhand der Konfiguration ihrer Unit-Datei. Dabei werden Abhängigkeiten zu anderen Units beachtet und ggf. Standardabhängigkeiten hinzugefügt, damit systemd die Dienste und Prozesse fehlerfrei ausführen kann.
Oft ist es nötig, “systemctl start” und “systemctl enable” für eine Unit durchzuführen, um sie sowohl sofort als auch nach einem Reboot verfügbar zu machen. Beide Optionen vereint der Befehl:
Nachfolgend zwei Befehle deren Funktion unsere Handbuchseite Systemd-Target beschreibt.
Beispiel
Anhand von Bluetooth demonstrieren wir die Funktionalität des
systemd.
Zuerst die Statusabfrage im Kurzformat.
# systemctl is-enabled bluetooth.service
enabledNun Suchen wir nach den Unit-Dateien, dabei kombinieren wir “systemctl” mit “grep”:
# systemctl list-unit-files | grep blue
bluetooth.service enabled enabled
dbus-org.bluez.service alias -
bluetooth.target static - Anschließend deaktivieren wir die Unit “bluetooth.service”.
# systemctl disable bluetooth.service
Synchronizing state of bluetooth.service with SysV service
script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable bluetooth
Removed /etc/systemd/system/dbus-org.bluez.service.
Removed /etc/systemd/system/bluetooth.target.wants/bluetooth.service.In der Ausgabe ist gut zu erkennen, dass die Link (nicht die Unit-Datei selbst) entfernt wurden. Damit startet der “bluetooth.service” beim Booten des PC/Laptop nicht mehr automatisch. Zur Kontrolle fragen wir den Status nach einem Reboot ab.
# systemctl is-enabled bluetooth.service
disabledUm eine Unit nur zeitweise zu deaktivieren, verwenden wir den Befehl
# systemctl stop <unit>Damit bleibt die Konfiguration in systemd erhalten. Mit dem entsprechenden “start”-Befehl aktivieren wir die Unit wieder.
Deutsche
Manpage ‘systemd’
Deutsche
Manpage ‘systemd.unit’
Deutsche
Manpage ‘systemd.syntax’