staging.inyokaproject.org

Von „systemd/Unit“ weitergeleitet.

Units

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:


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 Description enthä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 WantedBy legt fest, wann die Unit gestartet wird, was den früheren "run levels" entspricht. Der Wert multi-user.target ist 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.

intern

extern

Diese Revision wurde am 2. Februar 2023 15:38 von kB erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: System, systemd, Dienste