Units
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
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). Units werden z.B. für Dienste, Timer, Einhängepunkte, Sockets, Swap-Speicher und Geräte (devices) erstellt.
Allen Arten von Unit-Dateien haben gemeinsam, dass sie eine Struktur ähnlich Ini-Dateien haben. Sie bestehen aus mehreren Abschnitten (in den meisten Fällen drei), im Jargon von systemd als "Sektionen" bezeichnet, in der eine Reihen von Schlüssel-Werte Paaren, im Jargon von systemd "Direktiven", abgelegt sind.
Installation¶
Da systemd seit Ubuntu 15.04 integraler Bestandteil des Systems ist (und dieses ohne systemd nicht lauffähig ist), sind alle benötigten Komponenten bereits installiert.
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 benutzerbezogene Units, die jeder Benutzer für sich selbst erstellen, (de)aktivieren oder anpassen kann.
Systemweite Units¶
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 oder editiert werden. 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.
benutzerbezogene Units¶
Die Speicherorte von benutzerbezogendne Units werden im Artikel User Units aufgeführt.
Typen von Units¶
Es existieren verschiedene Typen von Units, die von systemd je nach Endung des Dateinamens unterschiedlich behandelt werden:
| Typ | Beschreibung | Wiki-Artikel |
.device | Legt Gerätedateien an | |
.mount | Ein- und Aushängen von Dateisystemen | Mount Units |
.path | Eine Service Unit in Abhängigkeit einer Änderung an einer Datei oder einem Verzeichnis ausführen | Path Units |
.network | Für die Konfiguration von Netzwerken | networkd |
.service | Für Dienste | Service Units |
.socket | Stellt Verbindungen zwischen Prozessen her | |
.target | Definiert eine Gruppe von Units | |
.timer | Für wiederkehrende Aufgaben, ähnlich Cron-Jobs | Timer Units |
Eigene Units anlegen¶
Units bestehen normalerweise aus einer einzelnen Datei. Diese hat eine Syntax und einen Aufbau ähnlich wie INI-Dateien. Das heißt, dass eckige Klammern Abschnitte ("sections") innerhalb der Datei markieren und innerhalb dieser Schlüssel-Werte-Paare angegeben werden.
Die allgemeine Struktur einer Unit-Datei sieht wie folgt aus:
[Unit] Description=Meine Unit [<UNIT-TYP>] # spezielle Schlüssel-Wert-Paare für den entsprechenden Unit-Typ [Install] WantedBy=multi-user.target
Es gibt also drei Sektionen:
"[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ängikeiten - 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]": Der Schlüssel
WantedBylegt fest, wann die Unit gestartet wird, was den früheren "run levels" entspricht. Der Wertmulti-user.targetist dabei der Standard für ein Mehrbenutzersystem (auch ohne grafische Oberfläche, wie z.B. Server).
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 die [Unit]-Sektion¶
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 andere Unit fehlt (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.
[Install]: WantedBy-Arten¶
Im Abschnitt "[Install]" wird mit dem Schlüssel WantedBy angegeben, wann die Unit gestartet wird. Es sind verschiedene Werte möglich:
| Target | Beschreibung |
multi-user.target | für Mehrbenutzersystem, mit oder ohne grafische Anmeldung (entspricht Runlevel 3) |
graphical.target | für Mehrbenutzersystem, die aber eine grafische Anmelde-Oberfläche haben müssen (entspricht Runlevel 3 plus grafischer Anmeldung) |
rescue.target | Einzelnutzer-Modus, wird in der Regel nur zur Systemrettung benötigt (entspricht 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.
Selbst angelegte Units aktivieren¶
Hat man eine systemweite Unit 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
Unit Datei editieren oder anlegen¶
Das Bearbeiten und Neuanlegen einer Unit-Datei ist in systemd/systemctl (Abschnitt „Bearbeiten-von-Unit-Dateien“) ausführlich beschrieben.
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
Zum rückgängig machen dient der Befehl:
sudo systemctl unmask NAME_DER_UNIT_DATEI.TYP
Benutzerbezogene Units steuern¶
Details zu benutzerbezogenen Units und Unterschiede zu systemweiten Units sind im Wikiartikel User Units beschrieben.
Links¶
intern¶
systemd-analyze - den Startvorgang des Systems und der Units analysieren und ggf. optimieren
extern¶
systemd Wiki 🇬🇧 - Dokumentation