[[Vorlage(Getestet, noble, jammy)]] {{{#!vorlage Wissen [:mit Root-Rechten arbeiten:] [:Terminal: Ein Terminal öffnen] [:Editor:Einen Editor öffnen] }}} [[Inhaltsverzeichnis()]] 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 Unit-Arten] zu finden. Alle Arten von Units liegen in Form einer einzelnen Textdatei vor, die eine Struktur ähnlich einer [wikiepdia:Initialisierungsdatei: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: {{{#!vorlage Tabelle <-3 tableclass="zebra_start3" rowclass="titel" :>Unit-Arten +++ Unit-Art <:>Dateiendung <:>Beschreibung +++ Service '''.service''' [:systemd/Service Units: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-Units 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''' [:systemd/Timer Units: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''' [:systemd/Path Units: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''' [:systemd/Mount Units:Mount Units] dienen zur Einbindung von Dateisystemen ins System. systemd liest beim Systemstart die Datei [:fstab:/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 Target Units] definieren Zustände, welche das System ansteuern, erreichen oder durchlaufen kann.. Ein Beispiel ist 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-Sektion-Unit Optionen für die Sektion [Unit\]], bzw. man kann eigene Units durch deren Aktivierung zu Targets hinzufügen, siehe Abschnitt [#Install-WantedBy-Arten Install] weiter unten. Man kann sich alle auf dem System vorhandenen Targets über den Befehl {{{#!vorlage 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: {{{#!vorlage 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 [:systemd/User Units: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: {{{#!vorlage Befehl 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 [:systemd/User Units:User Units] aufgeführt. == Units anlegen == Das Bearbeiten und Neuanlegen einer Unit-Datei ist in [:systemd/systemctl/#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: 1. Die 1. Sektion heißt in der Regel `[Unit]`. 1. Die 2. Sektion lautet wie der Typ der Unit (also z.B. `[Service]`, `[Timer]` etc.). 1. Die 3. Sektion lautet `[Install]`. Die allgemeine Struktur einer Unit-Datei sieht wie folgt aus: {{{ [Unit] Description=Bezeichnung der Unit [] # 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 `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ängigkeiten - den Überblick behält. * ''"[]"'': 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 [wikipedia:Binnenmajuskel:CamelCase]-Schreibweise geschrieben werden. [[Anker(Optionen-Sektion-Unit) ]] === Optionen für Sektion [Unit] === In der Sektion ''"[Unit]"'' können unter anderem folgende Schlüssel eingefügt werden: {{{#!vorlage tabelle 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 [https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BUnit%5D%20Section%20Options Dokumentation] {en} 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`. {{{#!vorlage Tabelle 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 [https://www.freedesktop.org/software/systemd/man/systemd.special.html Dokumentation] {en} von systemd zu finden. == Units anzeigen == Man kann sich alle laufenden Units mit Hilfe des folgenden Befehls anzeigen lassen: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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 [:systemd/systemctl:systemctl] mit Root-Rechten[1][2]: {{{#!vorlage Befehl sudo systemctl enable NAME_DER_UNIT_DATEI.TYP }}} Zum Deaktivieren dient der Befehl: {{{#!vorlage Befehl sudo systemctl disable NAME_DER_UNIT_DATEI.TYP }}} Um zu prüfen, ob eine Unit aktiv ist, führt man folgenden Befehl aus: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl sudo systemctl mask NAME_DER_UNIT_DATEI.TYP }}} Folgender Befehl macht das rückgängig: {{{#!vorlage Befehl sudo systemctl unmask NAME_DER_UNIT_DATEI.TYP }}} = Links = == intern == * [:systemd/systemd-analyze:systemd-analyze] -- Startvorgang des Systems und der Units analysieren und ggf. optimieren * [:systemd/Service_Units:] == extern == * [https://www.freedesktop.org/wiki/Software/systemd/ systemd Wiki] {en} - Dokumentation #tag: System, systemd, Dienste