Units
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Ubuntu 24.04 Noble Numbat
Ubuntu 22.04 Jammy Jellyfish
Ubuntu 20.04 Focal Fossa
Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
In systemd ist eine Organisationseinheit eine "Unit" (auf Deutsch: Einheit). Es gibt eine ganze Reihe von verschiedenen Units für verschiedene Zwecke, eine Auflistung ist im Abschnitt Unit-Arten zu finden.
Alle Arten von Units liegen in Form einer einzelnen Textdatei vor, die eine Struktur ähnlich einer Ini-Datei haben. Sie bestehen aus mehreren Abschnitten (in den meisten Fällen drei), im Jargon von systemd als „Sektionen“ bezeichnet, in den eine Reihe von Schlüssel-Wert-Paaren, im Jargon von systemd „Direktiven“, abgelegt sind.
Units können mehrere mögliche Ursprünge haben: Sie können Teil der Installation eines Pakets für ein Programm sein, sie können manuell von einem Nutzer angelegt werden, oder sie können dynamisch zur Laufzeit des System generiert werden.
Installation¶
Seit Ubuntu 15.04 ist systemd integraler Bestandteil des Systems (und dieses ist ohne systemd nicht lauffähig), somit sind alle benötigten Komponenten bereits installiert.
Unit-Arten¶
Es gibt verschiedene Arten von Units, die jeweils eine eigene Dateiendung haben. Diese Units sind:
| Unit-Arten | ||
| Unit-Art | Dateiendung | Beschreibung |
| Service | .service | 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 startet, wenn Unit A läuft oder dass die Unit erst gestartet wird, wenn ein bestimmtes in Form einer Target Unit (siehe unten) definiertes Ziel erreicht wurde. Außerdem können Units überwachen, ob der darin gestartete Prozess noch läuft und diesen im Falle eines Crashs neu starten. |
| Timer | .timer | Timer Units starten periodisch oder zu einem bestimmten Zeitpunkt eine andere Service Unit und übernehmen so Aufgaben, die früher mittels cron, at und ähnlichen Tools umgesetzt wurden. |
| Path | .path | Path Units überwachen Verzeichnisse bzw. Dateien und führen Service Units aus, wenn z.B. im überwachten Verzeichnis eine neue Datei angelegt oder eine bestehende verändert wurde. Dafür nutzen sie im Hintergrund inotify. |
| Mount | .mount | Mount Units dienen zur Einbindung von Dateisystemen ins System. systemd liest beim Systemstart die Datei /etc/fstab ein und generiert aus den Einträgen Mount Units. Von daher hat man die Wahl, ein Dateisystem dort einzutragen oder direkt eine eigene Mount Unit zu erstellen. |
| Automount | .automount | Automount Units dienen zum dynamischen Einbinden von Dateisystemen, d.h. die Einbindung erfolgt erst beim Zugriff auf das Dateisystem. Für jede Automount Unit muss eine passende Mount Unit existieren. Die Automount Unit überwacht den Zugriff und ruft dann, wenn dieser erfolgt, die passenden Mount Unit auf. |
| Socket | .socket | Socket Units dienen zum Überwachen von Netzwerk Sockets, FIFO Dateien ("named pipes") und Sockets, die zur Interprozesskommunikation eingesetzt werden. Jeder Socket Unit ist eine Service Unit zugeordnet, die ausgeführt wird, wenn Datenverkehr auf dem überwachten Socket eintrifft. |
| Device | .device | 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 | .swap | Eine Swap Unit dient zum Verwalten einer Swap Partition bzw. einer Swap Datei. |
| Target | .target | Target Units definieren Zustände, welche das System ansteuern, erreichen oder durchlaufen kann.. 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 von Service Units referenziert werden, so dass diese geladen und ausgeführt werden, wenn systemd die Aufgaben zum Erreichen eines Targets abarbeitet. |
| Slice | .slice | 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 | .scope | Scope Units bündeln und gruppieren Arbeitsprozesse des Systems. Sie werden dynamisch seitens systemd angelegt und nicht über Dateien definiert. |
Target Units¶
Target Units spielen eine wichtige Sonderrolle. Sie definieren, wie oben bereits erwähnt, das Erreichen von bestimmten Zuständen des Systems. In Abhängigkeit dessen kann man Units starten lassen, siehe Optionen für die Sektion [Unit], bzw. man kann eigene Units durch deren Aktivierung zu Targets hinzufügen, siehe Abschnitt Install weiter unten.
Man kann sich alle auf dem System vorhandenen Targets über den Befehl
systemctl list-units --type=target --all
anzeigen lassen. Möchte man nur die Target-Units sehen, die bis zum aktuellen Zeitpunkt erreicht wurden, geschieht das mit dem Befehl:
systemctl list-units --type=target
Benutzung¶
Dateien für Units sind unter Ubuntu an verschiedenen Stellen im Dateisystem abgelegt.
Zum einen gibt es systemweite Units, die nur mit Root-Rechten[1] angelegt oder editiert werden können.
Zum anderen gibt es benutzereigene Units, die jeder Benutzer für sich selbst erstellen, (de)aktivieren oder anpassen kann. Details zu Units von Benutzern und Unterschiede zu systemweiten Units beschreibt der Wikiartikel User Units.
Units des Systems¶
Es gibt etliche Order zur möglichen Ablage von Dateien für Units, welche man sich mit diesem Befehl anzeigen lassen kann:
systemd-analyze unit-paths
Die wichtigsten und häufig verwendeten Orte sind:
/lib/systemd/system: Hier liegen alle Dateien von Units, welche durch Dienste systemweit vorinstalliert worden sind. Diese Dateien sollten nie editiert werden.
/etc/systemd/system: Hier liegen alle Dateien von systemweiten Units, welche durch Nutzer angelegt wurden oder editiert werden können. Dazu sind Root-Rechte erforderlich.
Liegen unter /etc/systemd/system Unit-Dateien mit dem gleichen Namen wie unter /lib/systemd/system, so wird denen aus /etc/systemd/system der Vorzug gegeben, d.h. diese werden vom System geladen.
Die unter /run befindlichen Unit-Dateien sind solche, die zur Laufzeit des Systems angelegt worden sind.
Units eines Benutzers¶
Die Speicherorte für einem bestimmten Benutzer gehörenden Units werden im Artikel User Units aufgeführt.
Units anlegen¶
Das Bearbeiten und Neuanlegen einer Unit-Datei ist in systemd/systemctl (Abschnitt „Bearbeiten-von-Unit-Dateien“) ausführlich beschrieben.
Units bestehen normalerweise aus einer einzelnen Datei mit in der Regel drei Abschnitten ("sections"), in denen die Direktiven als Schlüssel-Wert-Paare angelegt sind:
Die 1. Sektion heißt in der Regel
[Unit].Die 2. Sektion lautet wie der Typ der Unit (also z.B.
[Service],[Timer]etc.).Die 3. Sektion lautet
[Install].
Die allgemeine Struktur einer Unit-Datei sieht wie folgt aus:
[Unit] Description=Bezeichnung der Unit [<UNIT-TYP>] # spezielle Schlüssel-Wert-Paare für den entsprechenden Unit-Typ [Install] WantedBy= (Name des Targets, mit dem die Unit gestartet wird, z.B. multi-user.target)
Erläuterung:
"[Unit]": Der Schlüssel
Descriptionenthält den Namen der Unit. Meist kann dieser frei gewählt werden (Ausnahmen werden im Artikel der jeweiligen Unit behandelt). Der Name sollte aber aussagekräftig sein, damit man - bspw. bei der Definition von Abhängigkeiten - den Überblick behält."[<UNIT-TYP>]": Hier wird als Schlüssel der Typ der Unit eingetragen (siehe Tabelle oben). In diesem Abschnitt folgen Schlüssel-Wert-Paare für den entsprechenden Unit-Typ.
"[Install]": Hier gibt es in der Regel nur den Schlüssel
WantedBy. Dieser legt fest, welchem Target die Unit zugeordnet wird, womit auch implizit mit festgelegt wird, im Rahmen welchen Vorgangs die Unit mit gestartet wird.
Gerade beim Anlegen eigener Units ist zu beachten, dass die Schlüssel immer mit Großbuchstaben beginnen und in CamelCase-Schreibweise geschrieben werden.
Optionen für Sektion [Unit]¶
In der Sektion "[Unit]" können unter anderem folgende Schlüssel eingefügt werden:
| Schlüssel | Erklärung |
Description | Ein aussagekräftiger Name für die Unit. Dieser Schlüssel ist Pflicht. |
Requires | Hier kann hinterlegt werden, welche andere Unit mit gestartet wird, wenn die eigene Unit gestartet wird. Wird Requires nicht erfüllt, startet die eigene Unit nicht. |
Requisite | Eine Variante zu Requires: Ist die hier angegebene Unit nicht bereits gestartet, startet die eigene Unit nicht und endet mit einem Fehler. |
BindsTo | Dies ist die „harte“ Variante von Requires. Wird die hier hinterlegte Unit gestoppt, stoppt auch die eigene Unit. |
Wants | Dies ist die „schwache“ Variante von Requires. Es wird zuerst geprüft, ob die bei Wants eingetragene Unit läuft oder gestartet werden kann, dann wird die eigene Unit gestartet. Schlägt der Start der anderen Unit fehl (oder wird diese gestoppt), läuft die eigene Unit aber trotzdem (weiter). |
Before | Legt fest, dass die eigene Unit vor den in Before eingetragenen Units gestartet werden soll. |
After | Legt fest, dass die eigene Unit nach den in After eingetragenen Units gestartet werden soll. |
Bei Requires, Wants etc. können auch mehrere Werte zu dem Schlüssel hinterlegt werden. Die Werte müssen dann durch ein Leerzeichen getrennt sein, also z.B. Requires=mysql.service apache2.service.
Eine vollständige Übersicht über alle möglichen Schlüssel mit ausführlicher Erklärung ist in der Dokumentation 🇬🇧 von systemd zu finden.
Mit den Schlüsseln Requires, After etc. lässt sich kontrollieren, wann eine Unit gestartet wird und es lässt sich sicherstellen, dass benötigte Units (in Form von Programmen, Laufwerken, anderen Ressourcen) laufen, bevor die eigene Unit startet. Beim Schlüssel After (und anderen Schlüsseln) kann man auch Target-Units als Wert angeben. Hat man z.B. eine Serveranwendung, die eine Netzwerkverbindung benötigt, kann man dies über das Schlüssel-Wert-Paar After=network-online.target sicherstellen.
Gibt man keine Schlüssel wie Requires, After etc. in der [Unit] Sektion an, wird die Unit so früh wie möglich gestartet.
[Install]: WantedBy-Arten¶
Im Abschnitt "[Install]" wird mit dem Schlüssel WantedBy angegeben, welchem Target die Unit zugeordnet ist. Damit ist auch implizit festgelegt, wann die Unit mit gestartet wird. Möchte man z.B. einen Dienst / Server beim System(neu)start starten, wählt man als Wert für WantedBy den Wert multi-user.target.
| Target | Beschreibung |
multi-user.target | Entspricht einem Mehrbenutzersystem, mit oder ohne grafische Anmeldung (wie früher Runlevel 3). |
graphical.target | Eintspricht einem Mehrbenutzersystem mit einer grafischen Anmelde-Oberfläche (wie früher Runlevel 3 plus grafischer Anmeldung). |
rescue.target | Der Einzelnutzer-Modus wird in der Regel nur zur Systemrettung benötigt (entspricht dem früheren Runlevel 1). |
reboot.target | Unit wird nur bei einem Neustart des Systems ausgeführt. |
poweroff.target | Unit wird nur beim Herunterfahren des Systems ausgeführt. |
default.target | Das default.target ist kein "echtes" Target, sondern ein symbolischer Link auf ein anderes, real existierendes Target. In der Standardinstallation des Ubuntu-Desktops ist das default.target das graphical.target. |
Eine vollständige Übersicht über alle Targets inklusive Erklärung ist in der Dokumentation 🇬🇧 von systemd zu finden.
Units anzeigen¶
Man kann sich alle laufenden Units mit Hilfe des folgenden Befehls anzeigen lassen:
systemctl list-units --all
Units als Dateien anzeigen¶
Man kann sich den Namen sowie den Zustand von Unit-Dateien mit Hilfe des folgenden Befehls anzeigen lassen:
systemctl list-unit-files
Unit aktivieren¶
Hat man eine Unit für das System angelegt, muss man diese noch aktivieren. Diese geschieht über den Befehl systemctl mit Root-Rechten[1][2]:
sudo systemctl enable NAME_DER_UNIT_DATEI.TYP
Zum Deaktivieren dient der Befehl:
sudo systemctl disable NAME_DER_UNIT_DATEI.TYP
Um zu prüfen, ob eine Unit aktiv ist, führt man folgenden Befehl aus:
sudo systemctl is-enabled NAME_DER_UNIT_DATEI.TYP
Laden von Units komplett verhindern¶
Auch wenn eine Unit über systemctl disable NAME_DER_UNIT_DATEI.TYP deaktiviert ist, kann diese von systemd geladen und gestartet werden, nämlich dann, wenn die Unit als Abhängigkeit von einer anderen Unit angefordert ist.
Um das Laden komplett zu verhindern, dient der folgende Befehl:
sudo systemctl mask NAME_DER_UNIT_DATEI.TYP
Folgender Befehl macht das rückgängig:
sudo systemctl unmask NAME_DER_UNIT_DATEI.TYP
Links¶
intern¶
systemd-analyze – Startvorgang des Systems und der Units analysieren und ggf. optimieren
extern¶
systemd Wiki 🇬🇧 - Dokumentation