TOC

Grundlegendes zu Systemd-Einheiten und Einheitendateien

Einführung

Zunehmend übernehmen oder planen Linux-Distributionen das Init-System "+ systemd +". Diese leistungsstarke Software-Suite kann viele Aspekte Ihres Servers verwalten, von Diensten über gemountete Geräte bis hin zu Systemzuständen.

In + systemd + bezieht sich ein + unit + auf jede Ressource, die das System bedienen und verwalten kann. Dies ist das Hauptobjekt, mit dem die Werkzeuge "+ systemd +" umgehen können. Diese Ressourcen werden mithilfe von Konfigurationsdateien definiert, die als Einheitendateien bezeichnet werden.

In diesem Handbuch stellen wir Ihnen die verschiedenen Einheiten vor, mit denen + systemd + umgehen kann. Wir werden auch einige der vielen Direktiven behandeln, die in Unit-Dateien verwendet werden können, um die Art und Weise zu beeinflussen, wie diese Ressourcen auf Ihrem System behandelt werden.

Was bieten Ihnen Systemd-Einheiten?

Einheiten sind die Objekte, die + systemd + verwalten kann. Dies ist im Grunde eine standardisierte Darstellung von Systemressourcen, die von der Daemon-Suite verwaltet und von den bereitgestellten Dienstprogrammen bearbeitet werden können.

Einheiten können in gewisser Weise als ähnlich zu Diensten oder Jobs in anderen Init-Systemen bezeichnet werden. Eine Einheit hat jedoch eine viel breitere Definition, da diese zum Abstrahieren von Diensten, Netzwerkressourcen, Geräten, Dateisystem-Bereitstellungen und isolierten Ressourcenpools verwendet werden können.

Ideen, die in anderen init-Systemen mit einer einheitlichen Service-Definition behandelt werden können, können entsprechend ihrem Fokus in Komponenten-Einheiten aufgeteilt werden. Dies ist nach Funktionen organisiert und ermöglicht es Ihnen, Funktionen auf einfache Weise zu aktivieren, zu deaktivieren oder zu erweitern, ohne das Kernverhalten einer Einheit zu ändern.

Einige Funktionen, die Einheiten problemlos implementieren können, sind:

  • * Socket-basierte Aktivierung *: Sockets, die einem Dienst zugeordnet sind, werden am besten aus dem Daemon selbst herausgebrochen, um separat behandelt zu werden. Dies bietet eine Reihe von Vorteilen, z. B. die Verzögerung des Starts eines Dienstes bis zum ersten Zugriff auf den zugeordneten Socket. Auf diese Weise kann das System zu Beginn des Startvorgangs alle Sockets erstellen und die zugehörigen Dienste parallel starten.

  • * Busbasierte Aktivierung *: Einheiten können auch über die von + D-Bus + bereitgestellte Busschnittstelle aktiviert werden. Ein Gerät kann gestartet werden, wenn ein zugehöriger Bus veröffentlicht wird.

  • * Pfadbasierte Aktivierung *: Eine Einheit kann basierend auf der Aktivität oder der Verfügbarkeit bestimmter Dateisystempfade gestartet werden. Dies verwendet "+ inotify +".

  • * Gerätebasierte Aktivierung *: Einheiten können auch bei der ersten Verfügbarkeit der zugehörigen Hardware durch Nutzung von "+ udev +" - Ereignissen gestartet werden.

  • * Implizite Abhängigkeitszuordnung *: Der größte Teil des Abhängigkeitsbaums für Einheiten kann von + systemd + selbst erstellt werden. Sie können immer noch Abhängigkeits- und Bestellinformationen hinzufügen, aber das meiste Heben wird für Sie erledigt.

  • * Instanzen und Vorlagen *: Mit Vorlagen-Einheitendateien können mehrere Instanzen derselben allgemeinen Einheit erstellt werden. Dies ermöglicht geringfügige Abweichungen oder Geschwistereinheiten, die alle dieselbe allgemeine Funktion haben.

  • * Einfache Sicherheitshärtung *: Einheiten können einige recht gute Sicherheitsfunktionen implementieren, indem sie einfache Anweisungen hinzufügen. Beispielsweise können Sie keinen oder nur Lesezugriff auf einen Teil des Dateisystems festlegen, die Kernelfunktionen begrenzen und privaten "+ / tmp +" - und Netzwerkzugriff zuweisen.

  • * Drop-Ins und Snippets *: Einheiten können einfach erweitert werden, indem Snippets bereitgestellt werden, die Teile der Einheitendatei des Systems überschreiben. Dies erleichtert das Umschalten zwischen Vanille- und benutzerdefinierten Einheitenimplementierungen.

Es gibt viele andere Vorteile, die + systemd + - Einheiten gegenüber den Arbeitselementen anderer Init-Systeme haben, aber dies sollte Ihnen eine Vorstellung davon geben, welche Leistung mit nativen Konfigurationsanweisungen genutzt werden kann.

Wo werden Systemd Unit-Dateien gefunden?

Die Dateien, die definieren, wie "+ systemd +" eine Einheit handhabt, befinden sich an vielen verschiedenen Stellen, von denen jede unterschiedliche Prioritäten und Auswirkungen hat.

Die Kopie der Unit-Dateien des Systems befindet sich normalerweise im Verzeichnis "+ / lib / systemd / system +". Wenn die Software Einheitendateien auf dem System installiert, ist dies der Speicherort, an dem sie standardmäßig abgelegt werden.

Hier gespeicherte Gerätedateien können während einer Sitzung bei Bedarf gestartet und gestoppt werden. Hierbei handelt es sich um die generische Vanille-Unit-Datei, die häufig von den Betreuern des Upstream-Projekts geschrieben wird und auf jedem System funktionieren sollte, das in seiner Standardimplementierung "+ systemd +" einsetzt. Sie sollten keine Dateien in diesem Verzeichnis bearbeiten. Stattdessen sollten Sie die Datei bei Bedarf überschreiben, indem Sie einen anderen Speicherort für die Einheitendatei verwenden, der die Datei an diesem Speicherort ersetzt.

Wenn Sie die Funktionsweise eines Geräts ändern möchten, finden Sie dies am besten im Verzeichnis "+ / etc / systemd / system +". Gerätedateien in diesem Verzeichnis haben Vorrang vor allen anderen Speicherorten im Dateisystem. Wenn Sie die Systemkopie einer Unit-Datei ändern müssen, ist das Einfügen eines Ersatzes in dieses Verzeichnis die sicherste und flexibelste Möglichkeit, dies zu tun.

Wenn Sie nur bestimmte Anweisungen aus der Unit-Datei des Systems überschreiben möchten, können Sie tatsächlich Unit-Datei-Snippets in einem Unterverzeichnis bereitstellen. Mit diesen werden die Anweisungen der Systemkopie angehängt oder geändert, sodass Sie nur die Optionen angeben können, die Sie ändern möchten.

Der richtige Weg, dies zu tun, besteht darin, ein Verzeichnis zu erstellen, das nach der Unit-Datei benannt ist und an das + .d + angehängt ist. Für eine Unit mit dem Namen "+ example.service " kann ein Unterverzeichnis mit dem Namen " example.service.d " erstellt werden. In diesem Verzeichnis kann eine Datei mit der Endung " .conf +" verwendet werden, um die Attribute der Unit-Datei des Systems zu überschreiben oder zu erweitern.

Unter "+ / run / systemd / system" finden Sie auch einen Speicherort für die Definition von Laufzeiteinheiten. Unit-Dateien, die in diesem Verzeichnis gefunden werden, haben eine Priorität zwischen denen in "+ / etc / systemd / system " und " / lib / systemd / system +". Dateien an diesem Speicherort erhalten weniger Gewicht als der erstere Speicherort, jedoch mehr Gewicht als der letztere.

Der "+ systemd +" - Prozess selbst verwendet diesen Speicherort für dynamisch erstellte Unit-Dateien, die zur Laufzeit erstellt werden. In diesem Verzeichnis kann das Verhalten der Systemeinheit für die Dauer der Sitzung geändert werden. Alle in diesem Verzeichnis vorgenommenen Änderungen gehen beim Neustart des Servers verloren.

Arten von Einheiten

+ Systemd + kategorisiert Einheiten nach der Art der Ressource, die sie beschreiben. Der Typ einer Einheit lässt sich am einfachsten mit dem Typensuffix bestimmen, das an das Ende des Ressourcennamens angehängt wird. Die folgende Liste beschreibt die Einheiten, die für "+ systemd +" verfügbar sind:

  • * + .service + *: Eine Serviceeinheit beschreibt, wie ein Service oder eine Anwendung auf dem Server verwaltet wird. Dies beinhaltet, wie der Dienst gestartet oder gestoppt wird, unter welchen Umständen er automatisch gestartet werden soll, und die Abhängigkeits- und Bestellinformationen für verwandte Software.

  • * + .socket + *: Eine Socket-Unit-Datei beschreibt einen Netzwerk- oder IPC-Socket oder einen FIFO-Puffer, den + systemd + für die Socket-basierte Aktivierung verwendet. Diese haben immer eine zugeordnete "+ .service +" - Datei, die gestartet wird, wenn Aktivität auf dem von diesem Gerät definierten Socket angezeigt wird.

  • * + .device + *: Eine Einheit, die ein Gerät beschreibt, für das eine Verwaltung mit + systemd + durch + udev + oder das Dateisystem + sysfs + erforderlich ist. Nicht alle Geräte haben + .device + Dateien. Einige Szenarien, in denen "+ .device +" - Einheiten erforderlich sein können, dienen zum Bestellen, Montieren und Zugreifen auf die Geräte.

  • * + .mount + *: Diese Einheit definiert einen Mountpunkt auf dem System, der von + systemd + verwaltet werden soll. Diese sind nach dem Mount-Pfad benannt, wobei die Schrägstriche in Bindestriche geändert werden. Bei Einträgen in + / etc / fstab + können Einheiten automatisch erstellt werden.

  • * + .automount + *: Eine + .automount + - Einheit konfiguriert einen Mountpoint, der automatisch gemountet wird. Diese müssen nach dem Mount-Punkt benannt sein, auf den sie verweisen, und müssen eine übereinstimmende "+ .mount +" - Einheit haben, um die Besonderheiten des Mount zu definieren.

  • * + .swap + *: Dieses Gerät beschreibt den Swap Space im System. Der Name dieser Einheiten muss das Gerät oder den Dateipfad des Space widerspiegeln.

  • * + .target + *: Eine Zieleinheit wird verwendet, um Synchronisationspunkte für andere Einheiten beim Hochfahren oder Ändern des Status bereitzustellen. Sie können auch verwendet werden, um das System in einen neuen Zustand zu versetzen. Andere Einheiten geben ihre Beziehung zu Zielen an, um sich an die Operationen des Ziels zu binden.

  • * + .path + *: Diese Einheit definiert einen Pfad, der für die pfadbasierte Aktivierung verwendet werden kann. Standardmäßig wird eine "+ .service " - Einheit mit demselben Basisnamen gestartet, wenn der Pfad den angegebenen Status erreicht. Dies verwendet " inotify +", um den Pfad auf Änderungen zu überwachen.

  • * + .timer + *: Eine + .timer + Einheit definiert einen Timer, der von + systemd + verwaltet wird, ähnlich einem + cron + Job für verzögerte oder geplante Aktivierung. Eine passende Einheit wird gestartet, wenn der Timer erreicht ist.

  • * + .snapshot + *: Eine + .snapshot + Einheit wird automatisch durch den Befehl + systemctl snapshot + erstellt. Hiermit können Sie den aktuellen Status des Systems nach Änderungen wiederherstellen. Snapshots überstehen keine Sitzungen und werden zum Zurücksetzen temporärer Zustände verwendet.

  • * + .slice + *: Eine + .slice + - Einheit ist Linux-Kontrollgruppenknoten zugeordnet, sodass Ressourcen für alle mit dem Slice verbundenen Prozesse eingeschränkt oder zugewiesen werden können. Der Name spiegelt seine hierarchische Position innerhalb des "+ cgroup +" - Baums wider. Einheiten werden je nach Typ standardmäßig in bestimmten Slices platziert.

  • * + .scope + *: Scope-Einheiten werden automatisch von + systemd + anhand der von den Busschnittstellen empfangenen Informationen erstellt. Diese werden zum Verwalten von extern erstellten Systemprozessgruppen verwendet.

Wie Sie sehen, gibt es viele verschiedene Einheiten, die + systemd + zu verwalten wissen. Viele der Einheitentypen arbeiten zusammen, um Funktionen hinzuzufügen. Beispielsweise werden einige Einheiten verwendet, um andere Einheiten auszulösen und Aktivierungsfunktionen bereitzustellen.

Wir werden uns hauptsächlich auf "+ .service +" - Einheiten konzentrieren, da diese nützlich sind und die Konsistenz besteht, mit der Administratoren diese Einheiten verwalten müssen.

Anatomie einer Unit-Datei

Die interne Struktur von Unit-Dateien ist in Abschnitte unterteilt. Abschnitte werden durch ein Paar eckiger Klammern "` + [+ " und " +] + `" gekennzeichnet, wobei der Abschnittsname darin eingeschlossen ist. Jeder Abschnitt erstreckt sich bis zum Anfang des nachfolgenden Abschnitts oder bis zum Ende der Datei.

Allgemeine Eigenschaften von Unit Files

Abschnittsnamen sind klar definiert und unterscheiden zwischen Groß- und Kleinschreibung. Der Abschnitt "+ [Einheit] " wird daher * nicht * korrekt interpretiert, wenn er wie folgt geschrieben wird: " [EINHEIT] ". Wenn Sie nicht standardmäßige Abschnitte hinzufügen müssen, die von anderen Anwendungen als " systemd " analysiert werden sollen, können Sie dem Abschnittsnamen ein Präfix " X- +" hinzufügen.

In diesen Abschnitten werden das Verhalten von Einheiten und Metadaten mithilfe einfacher Anweisungen in einem Schlüsselwertformat definiert, dessen Zuweisung durch ein Gleichheitszeichen wie folgt angegeben wird:

[]
=
=

. . .

Im Falle einer Überschreibungsdatei (wie die in einem Verzeichnis + .. d + enthaltenen) können Direktiven zurückgesetzt werden, indem sie einer leeren Zeichenfolge zugewiesen werden. Beispielsweise kann die Systemkopie einer Unit-Datei eine Direktive enthalten, die auf einen Wert wie den folgenden festgelegt ist:

=

Das + default_value + kann in einer Überschreibungsdatei durch Verweisen auf ++ ohne einen Wert wie folgt entfernt werden:

=

Im Allgemeinen ermöglicht "+ systemd " eine einfache und flexible Konfiguration. Zum Beispiel werden mehrere boolesche Ausdrücke akzeptiert (` 1 `, ` yes `, ` on ` und ` true ` für bejahend und ` 0 `, ` no ` ` off +` und ` + false + `für die gegenteilige Antwort). Die Zeiten können intelligent analysiert werden, wobei Sekunden für Werte ohne Einheiten angenommen werden und mehrere intern durchgeführte Formate kombiniert werden.

Richtlinien der Sektion [Unit]

Der erste Abschnitt in den meisten Unit-Dateien ist der Abschnitt + [Unit] +. Dies wird im Allgemeinen zum Definieren von Metadaten für die Einheit und zum Konfigurieren der Beziehung der Einheit zu anderen Einheiten verwendet.

Obwohl die Abschnittsreihenfolge beim Parsen der Datei für "+ systemd " keine Rolle spielt, wird dieser Abschnitt häufig ganz oben platziert, da er einen Überblick über die Einheit bietet. Einige gebräuchliche Anweisungen, die Sie im Abschnitt " [Unit] +" finden, sind:

  • * + Description = + *: Mit dieser Anweisung können der Name und die Grundfunktionen des Geräts beschrieben werden. Es wird von verschiedenen + systemd + - Werkzeugen zurückgegeben, daher ist es gut, dies auf etwas Kurzes, Spezifisches und Informatives festzulegen.

  • * + Documentation = + *: Diese Direktive bietet einen Speicherort für eine Liste von URIs zur Dokumentation. Dies können entweder intern verfügbare "+ man " - Seiten oder über das Internet zugängliche URLs sein. Der Befehl " systemctl status" legt diese Informationen offen und ermöglicht so eine einfache Auffindbarkeit.

  • * + Requires = + *: Diese Direktive listet alle Einheiten auf, von denen diese Einheit im Wesentlichen abhängt. Wenn die aktuelle Einheit aktiviert ist, müssen auch die hier aufgelisteten Einheiten erfolgreich aktiviert werden, andernfalls fällt diese Einheit aus. Diese Einheiten werden standardmäßig parallel zur aktuellen Einheit gestartet.

  • * + Wants = + *: Diese Anweisung ähnelt der Anweisung + Requires = +, ist jedoch weniger streng. + Systemd + versucht, alle hier aufgelisteten Einheiten zu starten, wenn diese Einheit aktiviert ist. Wenn diese Einheiten nicht gefunden werden oder nicht gestartet werden können, funktioniert die aktuelle Einheit weiterhin. Dies ist die empfohlene Methode zum Konfigurieren der meisten Abhängigkeitsbeziehungen. Dies impliziert wiederum eine parallele Aktivierung, sofern dies nicht durch andere Richtlinien geändert wurde.

  • * + BindsTo = + *: Diese Anweisung ähnelt + Requires = +, bewirkt jedoch auch, dass die aktuelle Unit stoppt, wenn die zugehörige Unit beendet wird.

  • * + Before = + *: Die in dieser Anweisung aufgeführten Einheiten werden erst gestartet, wenn die aktuelle Einheit als gestartet markiert ist, wenn sie gleichzeitig aktiviert werden. Dies impliziert keine Abhängigkeitsbeziehung und muss in Verbindung mit einer der oben genannten Richtlinien verwendet werden, wenn dies gewünscht wird.

  • * + After = + *: Die in dieser Direktive aufgelisteten Einheiten werden gestartet, bevor die aktuelle Einheit gestartet wird. Dies impliziert keine Abhängigkeitsbeziehung, und eine muss durch die obigen Richtlinien hergestellt werden, wenn dies erforderlich ist.

  • * + Conflicts = + *: Hiermit können Einheiten aufgelistet werden, die nicht gleichzeitig mit der aktuellen Einheit ausgeführt werden können. Wenn Sie eine Einheit mit dieser Beziehung starten, werden die anderen Einheiten angehalten.

  • * + Bedingung …​ = + *: Es gibt eine Reihe von Anweisungen, die mit + Bedingung + beginnen und es dem Administrator ermöglichen, bestimmte Bedingungen vor dem Starten des Geräts zu testen. Dies kann verwendet werden, um eine generische Unit-Datei bereitzustellen, die nur auf geeigneten Systemen ausgeführt wird. Wenn die Bedingung nicht erfüllt ist, wird das Gerät ordnungsgemäß übersprungen.

  • * + Assert …​ = + *: Ähnlich wie die Direktiven, die mit + Condition + beginnen, prüfen diese Direktiven verschiedene Aspekte der laufenden Umgebung, um zu entscheiden, ob das Gerät aktiviert werden soll. Im Gegensatz zu den Direktiven "+ Condition +" führt ein negatives Ergebnis jedoch zu einem Fehler bei dieser Direktive.

Mit diesen und einigen anderen Anweisungen können allgemeine Informationen über das Gerät und seine Beziehung zu anderen Geräten und dem Betriebssystem erstellt werden.

Anweisungen im Abschnitt [Install]

Auf der gegenüberliegenden Seite der Unit-Datei ist der letzte Abschnitt häufig der Abschnitt "+ [Install] +". Dieser Abschnitt ist optional und wird verwendet, um das Verhalten oder eine Einheit zu definieren, wenn sie aktiviert oder deaktiviert ist. Durch das Aktivieren einer Einheit wird diese beim Booten automatisch gestartet. Dies wird im Wesentlichen dadurch erreicht, dass die betreffende Einheit an einer anderen Einheit verriegelt wird, die sich irgendwo in der Reihe der Einheiten befindet, die beim Booten gestartet werden sollen.

Aus diesem Grund haben nur Einheiten, die aktiviert werden können, diesen Abschnitt. Die Anweisungen in bestimmen, was passieren soll, wenn das Gerät aktiviert wird:

  • * + WantedBy = + *: Die Anweisung + WantedBy = + ist die gebräuchlichste Methode, um anzugeben, wie eine Einheit aktiviert werden soll. Mit dieser Direktive können Sie eine Abhängigkeitsbeziehung auf ähnliche Weise wie mit der Direktive "+ Wants = " im Abschnitt " [Unit] " angeben. Der Unterschied besteht darin, dass diese Richtlinie in der Zusatzeinheit enthalten ist, sodass die aufgeführte Primäreinheit relativ sauber bleibt. Wenn eine Unit mit dieser Direktive aktiviert ist, wird ein Verzeichnis in " / etc / systemd / system " erstellt, das nach der angegebenen Unit benannt ist und an das " .wants " angehängt ist. Innerhalb dieser wird eine symbolische Verknüpfung zur aktuellen Einheit erstellt, wodurch die Abhängigkeit entsteht. Wenn zum Beispiel die aktuelle Einheit " WantedBy = multi-user.target " hat, wird ein Verzeichnis mit dem Namen " multi-user.target.wants " in " / etc / systemd / system +" erstellt (falls nicht bereits verfügbar) ) und ein symbolischer Link zur aktuellen Einheit wird innerhalb von platziert. Durch Deaktivieren dieses Geräts wird die Verknüpfung entfernt und die Abhängigkeitsbeziehung entfernt.

  • * + RequiredBy = + *: Diese Anweisung ist der Anweisung + WantedBy = + sehr ähnlich, gibt jedoch eine erforderliche Abhängigkeit an, die dazu führt, dass die Aktivierung fehlschlägt, wenn sie nicht erfüllt wird. Wenn diese Option aktiviert ist, erstellt eine Unit mit dieser Direktive ein Verzeichnis mit der Endung "+ .requires +".

  • * + Alias ​​= + *: Mit dieser Anweisung kann das Gerät auch unter einem anderen Namen aktiviert werden. Dies ermöglicht unter anderem, dass mehrere Anbieter einer Funktion verfügbar sind, sodass verwandte Einheiten nach jedem Anbieter des gemeinsamen Alias-Namens suchen können.

  • * + Also = + *: Mit dieser Anweisung können Einheiten als Gruppe aktiviert oder deaktiviert werden. Unterstützende Einheiten, die immer verfügbar sein sollten, wenn diese Einheit aktiv ist, können hier aufgelistet werden. Sie werden als Gruppe für Installationsaufgaben verwaltet.

  • * + DefaultInstance = + *: Für Vorlageneinheiten (später behandelt), die Einheiteninstanzen mit unvorhersehbaren Namen erzeugen können, kann dies als Ersatzwert für den Namen verwendet werden, wenn kein geeigneter Name angegeben wird.

Abschnittsspezifische Richtlinien

Zwischen den beiden vorherigen Abschnitten befinden sich wahrscheinlich gerätetypspezifische Abschnitte. Die meisten Gerätetypen bieten Richtlinien an, die nur für ihren spezifischen Typ gelten. Diese sind in Abschnitten verfügbar, die nach ihrem Typ benannt sind. Wir werden diese hier kurz behandeln.

Die Unit-Typen + device,` + target`, + snapshot und` + scope` haben keine unit-spezifischen Direktiven und daher keine zugeordneten Abschnitte für ihren Typ.

Der Abschnitt [Service]

Der Abschnitt "+ [Service] +" wird verwendet, um die Konfiguration bereitzustellen, die nur für Services gilt.

Eines der grundlegenden Dinge, die im Abschnitt "+ [Service] " angegeben werden sollten, ist der " Type = " des Service. Dies kategorisiert Dienste nach ihrem Prozess- und Dämonisierungsverhalten. Dies ist wichtig, da es " systemd +" mitteilt, wie der Dienst korrekt verwaltet und sein Status ermittelt werden soll.

Die Direktive + Type = + kann eine der folgenden sein:

  • * einfach *: Der Hauptprozess des Dienstes wird in der Startzeile angegeben. Dies ist die Standardeinstellung, wenn die Direktiven "+ Type = " und " Busname = " nicht gesetzt sind, aber " ExecStart = " gesetzt ist. Jegliche Kommunikation sollte außerhalb des Geräts über ein zweites Gerät des entsprechenden Typs abgewickelt werden (wie über ein " .socket +" - Gerät, wenn dieses Gerät über Sockets kommunizieren muss).

  • * forking *: Dieser Diensttyp wird verwendet, wenn der Dienst einen untergeordneten Prozess gabelt und den übergeordneten Prozess fast sofort verlässt. Dies teilt + systemd + mit, dass der Prozess noch ausgeführt wird, obwohl das übergeordnete Element beendet wurde.

  • * oneshot *: Dieser Typ zeigt an, dass der Prozess nur von kurzer Dauer ist und dass "+ systemd " auf den Abschluss des Prozesses warten sollte, bevor mit anderen Einheiten fortgefahren wird. Dies ist die Standardeinstellung. " Type = " und " ExecStart = +" sind nicht festgelegt. Es wird für einmalige Aufgaben verwendet.

  • * dbus *: Zeigt an, dass das Gerät einen Namen auf dem D-Bus-Bus erhält. In diesem Fall verarbeitet + systemd + die nächste Einheit weiter.

  • * benachrichtigen *: Dies zeigt an, dass der Dienst nach dem Start eine Benachrichtigung ausgibt. Der "+ systemd +" - Prozess wartet darauf, dass dies geschieht, bevor er mit anderen Einheiten fortfährt.

  • * idle *: Dies zeigt an, dass der Dienst erst ausgeführt wird, wenn alle Jobs gesendet wurden.

Bei Verwendung bestimmter Diensttypen sind möglicherweise einige zusätzliche Anweisungen erforderlich. Zum Beispiel:

  • * + RemainAfterExit = + *: Diese Direktive wird üblicherweise mit dem Typ + oneshot + verwendet. Es zeigt an, dass der Dienst auch nach dem Beenden des Prozesses als aktiv betrachtet werden sollte.

  • * + PIDFile = + *: Wenn der Diensttyp als "forking" markiert ist, wird mit dieser Anweisung der Pfad der Datei festgelegt, die die Prozess-ID-Nummer des Hauptkinds enthalten soll, das überwacht werden soll.

  • * + BusName = + *: Diese Anweisung sollte auf den D-Bus-Busnamen gesetzt werden, den der Dienst bei Verwendung des Diensttyps "dbus" zu ermitteln versucht.

  • * + NotifyAccess = + *: Gibt den Zugriff auf den Socket an, der zum Abhören von Benachrichtigungen verwendet werden soll, wenn der Diensttyp "Benachrichtigen" ausgewählt ist. Dies kann "Keine", "Haupt" oder "Alle" sein. Die Standardeinstellung "keine" ignoriert alle Statusmeldungen. Mit der Option "main" werden Nachrichten vom Hauptprozess abgehört, und mit der Option "all" werden alle Mitglieder der Kontrollgruppe des Dienstes verarbeitet.

Bisher haben wir einige erforderliche Informationen besprochen, aber wir haben noch nicht definiert, wie unsere Dienste verwaltet werden sollen. Die Anweisungen dazu sind:

  • * + ExecStart = + *: Gibt den vollständigen Pfad und die Argumente des Befehls an, der ausgeführt werden soll, um den Prozess zu starten. Dies darf nur einmal angegeben werden (außer bei OneShot-Diensten). Wenn dem Pfad zum Befehl ein Bindestrich „-“ vorangestellt ist, werden Beendigungsstatus ungleich Null akzeptiert, ohne dass die Aktivierung der Einheit als fehlgeschlagen markiert wird.

  • * + ExecStartPre = + *: Dies kann verwendet werden, um zusätzliche Befehle bereitzustellen, die ausgeführt werden sollten, bevor der Hauptprozess gestartet wird. Dies kann mehrfach verwendet werden. Auch hier müssen Befehle einen vollständigen Pfad angeben und können mit einem vorangestellten "-" versehen werden, um anzuzeigen, dass der Fehler des Befehls toleriert wird.

  • * + ExecStartPost = + *: Dies hat die gleichen Eigenschaften wie + ExecStartPre = +, außer dass es Befehle angibt, die nach dem Start des Hauptprozesses ausgeführt werden.

  • * + ExecReload = + *: Diese optionale Anweisung gibt den Befehl an, der zum erneuten Laden der Konfiguration des Dienstes erforderlich ist, falls verfügbar.

  • * + ExecStop = + *: Dies gibt den Befehl an, der zum Beenden des Dienstes benötigt wird. Wenn dies nicht angegeben wird, wird der Prozess sofort abgebrochen, wenn der Dienst beendet wird.

  • * + ExecStopPost = + *: Hier können Befehle angegeben werden, die nach dem Befehl stop ausgeführt werden sollen.

  • * + RestartSec = + *: Wenn der automatische Neustart des Dienstes aktiviert ist, gibt dies die Zeit an, die gewartet werden muss, bevor versucht wird, den Dienst neu zu starten.

  • * + Restart = + *: Dies gibt die Umstände an, unter denen + systemd + versucht, den Dienst automatisch neu zu starten. Dies kann auf Werte wie "Immer", "Erfolgreich", "Fehlgeschlagen", "Anormal", "Abbruch" oder "Wachhund" eingestellt werden. Diese lösen einen Neustart entsprechend der Art und Weise aus, in der der Dienst beendet wurde.

  • * + TimeoutSec = + *: Konfiguriert die Zeitspanne, die + systemd + beim Beenden oder Beenden des Dienstes wartet, bevor er als fehlgeschlagen oder gewaltsam beendet markiert wird. Sie können separate Timeouts auch mit + TimeoutStartSec = + und + TimeoutStopSec = + einstellen.

Der Abschnitt [Socket]

Socket-Einheiten sind in "+ systemd +" - Konfigurationen sehr verbreitet, da viele Dienste eine Socket-basierte Aktivierung implementieren, um eine bessere Parallelisierung und Flexibilität zu gewährleisten. Jede Socket-Einheit muss über eine passende Service-Einheit verfügen, die aktiviert wird, wenn die Socket-Aktivität empfangen wird.

Indem die Socket-Steuerung außerhalb des Dienstes selbst unterbrochen wird, können Sockets frühzeitig initialisiert und die zugehörigen Dienste häufig parallel gestartet werden. Standardmäßig versucht der Socket-Name, den gleichnamigen Dienst beim Empfang einer Verbindung zu starten. Wenn der Dienst initialisiert wird, wird der Socket an ihn übergeben, sodass er gepufferte Anforderungen verarbeiten kann.

Um den tatsächlichen Socket anzugeben, sind die folgenden Anweisungen üblich:

  • * + ListenStream = + *: Definiert eine Adresse für einen Stream-Socket, der eine sequenzielle, zuverlässige Kommunikation unterstützt. Dienste, die TCP verwenden, sollten diesen Socket-Typ verwenden.

  • * + ListenDatagram = + *: Definiert eine Adresse für einen Datagramm-Socket, der schnelle, unzuverlässige Kommunikationspakete unterstützt. Dienste, die UDP verwenden, sollten diesen Socket-Typ festlegen.

  • * + ListenSequentialPacket = + *: Definiert eine Adresse für die sequentielle, zuverlässige Kommunikation mit Datagrammen mit maximaler Länge, wobei die Nachrichtengrenzen erhalten bleiben. Dies wird am häufigsten für Unix-Sockets gefunden.

  • * + ListenFIFO + *: Neben den anderen Listening-Typen können Sie anstelle eines Sockets auch einen FIFO-Puffer angeben.

Es gibt mehr Arten von Höranweisungen, die oben genannten sind jedoch die am häufigsten verwendeten.

Andere Eigenschaften der Steckdosen können durch zusätzliche Anweisungen gesteuert werden:

  • * + Accept = + *: Bestimmt, ob für jede Verbindung eine zusätzliche Instanz des Dienstes gestartet wird. Bei false (Standardeinstellung) werden alle Verbindungen von einer Instanz verarbeitet.

  • * + SocketUser = + *: Gibt bei einem Unix-Socket den Eigentümer des Sockets an. Dies ist der Root-Benutzer, wenn er nicht festgelegt wird.

  • * + SocketGroup = + *: Gibt bei einem Unix-Socket den Gruppeneigentümer des Sockets an. Dies ist die Stammgruppe, wenn weder diese noch die oben genannten festgelegt sind. Wenn nur "+ SocketUser = " gesetzt ist, versucht " systemd +", eine passende Gruppe zu finden.

  • * + SocketMode = + *: Für Unix-Sockets oder FIFO-Puffer werden die Berechtigungen für die erstellte Entität festgelegt.

  • * + Service = + *: Wenn der Name des Dienstes nicht mit dem Namen von + .socket + übereinstimmt, kann der Dienst mit dieser Anweisung angegeben werden.

Der Abschnitt [Mount]

Mount Units ermöglichen die Verwaltung von Mount Points innerhalb von + systemd +. Bereitstellungspunkte werden nach dem Verzeichnis benannt, das sie steuern, wobei ein Übersetzungsalgorithmus angewendet wird.

Beispielsweise wird der führende Schrägstrich entfernt, alle anderen Schrägstriche werden in Bindestriche "-" übersetzt, und alle Bindestriche und nicht druckbaren Zeichen werden durch Escape-Codes im C-Stil ersetzt. Das Ergebnis dieser Übersetzung wird als Name der Mount-Unit verwendet. Mount-Einheiten haben eine implizite Abhängigkeit von anderen Mounts in der Hierarchie darüber.

Mount-Units werden während des Bootvorgangs häufig direkt aus + / etc / fstab + - Dateien übersetzt. Für die automatisch erstellten Einheitendefinitionen und diejenigen, die Sie in einer Einheitendatei definieren möchten, sind die folgenden Anweisungen hilfreich:

  • * + What = + *: Der absolute Pfad zu der Ressource, die gemountet werden muss.

  • * + Where = + *: Der absolute Pfad des Mountpunkts, an dem die Ressource gemountet werden soll. Dies sollte derselbe sein wie der Einheitendateiname, außer bei Verwendung der herkömmlichen Dateisystemnotation.

  • * + Type = + *: Der Dateisystemtyp des Mount.

  • * + Options = + *: Alle Mount-Optionen, die angewendet werden müssen. Dies ist eine durch Kommas getrennte Liste.

  • * + SloppyOptions = + *: Ein Boolescher Wert, der festlegt, ob der Mount fehlschlägt, wenn eine nicht erkannte Mount-Option vorhanden ist.

  • * + DirectoryMode = + *: Wenn übergeordnete Verzeichnisse für den Einhängepunkt erstellt werden müssen, bestimmt dies den Berechtigungsmodus dieser Verzeichnisse.

  • * + TimeoutSec = + *: Konfiguriert die Zeitspanne, die das System wartet, bis der Mount-Vorgang als fehlgeschlagen markiert wird.

Der Abschnitt [Automount]

Mit dieser Einheit kann eine zugeordnete "+ .mount " - Einheit beim Booten automatisch gemountet werden. Wie bei der Einheit " .mount +" müssen diese Einheiten nach dem Pfad des übersetzten Einhängepunkts benannt werden.

Der Abschnitt "+ [Automount] +" ist ziemlich einfach, nur die folgenden beiden Optionen sind zulässig:

  • * + Where = + *: Der absolute Pfad des Automount-Punkts auf dem Dateisystem. Dies stimmt mit dem Dateinamen überein, außer dass anstelle der Übersetzung die herkömmliche Pfadnotation verwendet wird.

  • * + DirectoryMode = + *: Wenn der Automount-Punkt oder ein übergeordnetes Verzeichnis erstellt werden muss, bestimmt dies die Berechtigungseinstellungen dieser Pfadkomponenten.

Der Abschnitt [Swap]

Swap Units werden verwendet, um den Swap Space auf dem System zu konfigurieren. Die Einheiten müssen nach der Auslagerungsdatei oder dem Auslagerungsgerät benannt sein und dieselbe Dateisystemübersetzung verwenden, die oben beschrieben wurde.

Wie die Mount-Optionen können die Swap-Units automatisch aus den Einträgen "+ / etc / fstab +" erstellt oder über eine dedizierte Unit-Datei konfiguriert werden.

Der Abschnitt "+ [Swap] +" einer Unit-Datei kann die folgenden Anweisungen zur Konfiguration enthalten:

  • * + What = + *: Der absolute Pfad zum Speicherort des Auslagerungsbereichs, unabhängig davon, ob es sich um eine Datei oder ein Gerät handelt.

  • * + Priorität = + *: Dies ist eine Ganzzahl, die die Priorität des zu konfigurierenden Swap angibt.

  • * + Options = + *: Alle Optionen, die normalerweise in der Datei + / etc / fstab + festgelegt werden, können stattdessen mit dieser Direktive festgelegt werden. Eine durch Kommas getrennte Liste wird verwendet.

  • * + TimeoutSec = + *: Die Zeitspanne, die + systemd + auf die Aktivierung des Swap wartet, bevor der Vorgang als fehlgeschlagen markiert wird.

Der Abschnitt [Pfad]

Eine Pfadeinheit definiert einen Dateisystempfad, den + systmed + auf Änderungen überwachen kann. Es muss eine andere Einheit vorhanden sein, die aktiviert wird, wenn bestimmte Aktivitäten am Pfadort erkannt werden. Die Pfadaktivität wird durch "+ inotify" -Ereignisse bestimmt.

Der Abschnitt "+ [Pfad] +" einer Unit-Datei kann die folgenden Anweisungen enthalten:

  • * + PathExists = + *: Mit dieser Anweisung wird geprüft, ob der betreffende Pfad existiert. Ist dies der Fall, wird die zugehörige Einheit aktiviert.

  • * + PathExistsGlob = + *: Dies ist das Gleiche wie oben, unterstützt jedoch Datei-Glob-Ausdrücke zur Bestimmung der Pfadexistenz.

  • * + PathChanged = + *: Überwacht die Pfadposition auf Änderungen. Die zugehörige Einheit wird aktiviert, wenn beim Schließen der überwachten Datei eine Änderung festgestellt wird.

  • * + PathModified = + *: Dies überwacht Änderungen wie die obige Direktive, wird jedoch sowohl beim Schreiben von Dateien als auch beim Schließen der Datei aktiviert.

  • * + DirectoryNotEmpty = + *: Mit dieser Direktive kann + systemd + die zugehörige Unit aktivieren, wenn das Verzeichnis nicht mehr leer ist.

  • * + Unit = + *: Gibt die Einheit an, die aktiviert werden soll, wenn die oben angegebenen Pfadbedingungen erfüllt sind. Wenn dies weggelassen wird, sucht "+ systemd " nach einer " .service +" - Datei, die denselben Basiseinheitsnamen wie diese Einheit hat.

  • * + MakeDirectory = + *: Bestimmt, ob + systemd + vor dem Ansehen die Verzeichnisstruktur des betreffenden Pfades erstellt.

  • * + DirectoryMode = + *: Wenn das oben Gesagte aktiviert ist, wird der Berechtigungsmodus für alle Pfadkomponenten festgelegt, die erstellt werden müssen.

Der Abschnitt [Timer]

Timer-Einheiten werden verwendet, um Aufgaben so zu planen, dass sie zu einer bestimmten Zeit oder nach einer bestimmten Verzögerung ausgeführt werden. Dieser Einheitentyp ersetzt oder ergänzt einige der Funktionen der Dämonen + cron + und + at +. Es muss eine zugehörige Einheit bereitgestellt werden, die aktiviert wird, wenn der Timer erreicht ist.

Der Abschnitt "+ [Timer] +" einer Unit-Datei kann einige der folgenden Anweisungen enthalten:

  • * + OnActiveSec = + *: Mit dieser Anweisung kann die zugehörige Einheit im Verhältnis zur Aktivierung der Einheit + .timer + aktiviert werden.

  • * + OnBootSec = + *: Mit dieser Anweisung wird die Zeitspanne nach dem Systemstart festgelegt, in der die zugehörige Einheit aktiviert werden soll.

  • * + OnStartupSec = + *: Diese Anweisung ähnelt dem obigen Timer, bezieht sich jedoch darauf, wann der Prozess + systemd + selbst gestartet wurde.

  • * + OnUnitActiveSec = + *: Stellt einen Timer ein, der davon abhängt, wann die zugehörige Einheit zuletzt aktiviert wurde.

  • * + OnUnitInactiveSec = + *: Hiermit wird der Timer in Bezug auf den Zeitpunkt gesetzt, zu dem die zugehörige Einheit zuletzt als inaktiv markiert wurde.

  • * + OnCalendar = + *: Hiermit können Sie die zugehörige Einheit aktivieren, indem Sie einen absoluten Wert anstelle eines relativen Werts für ein Ereignis angeben.

  • * + AccuracySec = + *: Mit diesem Gerät wird die Genauigkeit eingestellt, mit der der Timer eingehalten werden soll. Standardmäßig wird die zugehörige Einheit innerhalb einer Minute nach Erreichen des Timers aktiviert. Der Wert dieser Direktive bestimmt die oberen Grenzen des Fensters, in dem + systemd + die Aktivierung einplant.

  • * + Unit = + *: Mit dieser Anweisung wird die Einheit angegeben, die nach Ablauf des Timers aktiviert werden soll. Wenn nicht gesetzt, sucht "+ systemd " nach einer " .service +" - Einheit mit einem Namen, der dieser Einheit entspricht.

  • * + Persistent = + *: Wenn dies eingestellt ist, wird durch + systemd + die zugehörige Einheit ausgelöst, wenn der Timer aktiv wird, wenn er während des Zeitraums ausgelöst worden wäre, in dem der Timer inaktiv war.

  • * + WakeSystem = + *: Mit dieser Anweisung können Sie ein System aus dem Suspend-Modus aktivieren, wenn der Timer in diesem Zustand erreicht ist.

Der Abschnitt [Slice]

Der Abschnitt "+ [Slice] " einer Unit-Datei hat tatsächlich keine " .slice +" - Unit-spezifische Konfiguration. Stattdessen kann es einige Ressourcenverwaltungsanweisungen enthalten, die tatsächlich für eine Reihe der oben aufgeführten Einheiten verfügbar sind.

Einige gebräuchliche Direktiven im Abschnitt "+ [Slice] ", die auch in anderen Units verwendet werden können, finden Sie in der Manpage " systemd.resource-control +". Diese gelten in folgenden gerätespezifischen Abschnitten:

  • + [Slice] +

  • + [Scope] +

  • + [Service] +

  • + [Socket] +

  • + [Einhängen] +

  • + [Swap] +

Erstellen von Instanzeinheiten aus Vorlageneinheitendateien

Wir haben bereits in diesem Handbuch die Idee erwähnt, Vorlagen-Unit-Dateien zum Erstellen mehrerer Instanzen von Units zu verwenden. In diesem Abschnitt können wir dieses Konzept näher erläutern.

Template-Unit-Dateien unterscheiden sich in den meisten Fällen nicht von normalen Unit-Dateien. Diese bieten jedoch Flexibilität bei der Konfiguration von Einheiten, da bestimmte Teile der Datei dynamische Informationen verwenden können, die zur Laufzeit verfügbar sind.

Namen der Vorlagen- und Instanzeinheiten

Vorlagen-Unit-Dateien können identifiziert werden, weil sie nach dem Namen der Basis-Unit und vor dem Suffix des Unit-Typs ein "+ @ +" -Symbol enthalten. Der Name einer Vorlageneinheitsdatei kann folgendermaßen aussehen:

[email protected]

Wenn eine Instanz aus einer Vorlage erstellt wird, wird eine Instanzkennung zwischen dem Symbol "+ @ +" und dem Punkt eingefügt, der den Beginn des Einheitentyps kennzeichnet. Die obige Vorlageneinheitendatei könnte zum Beispiel verwendet werden, um eine Instanzeinheit zu erstellen, die folgendermaßen aussieht:

[email protected]

Eine Instanzdatei wird normalerweise als symbolischer Link zur Vorlagendatei erstellt, wobei der Linkname die Instanzkennung enthält. Auf diese Weise können mehrere Links mit eindeutigen Bezeichnern auf eine einzelne Vorlagendatei verweisen. Bei der Verwaltung einer Instanzeinheit sucht + systemd + nach einer Datei mit dem genauen Instanznamen, den Sie in der Befehlszeile angegeben haben. Wenn es keine findet, sucht es nach einer zugeordneten Vorlagendatei.

Template-Bezeichner

Die Leistungsfähigkeit von Vorlagen-Einheitendateien wird hauptsächlich durch die Fähigkeit zum dynamischen Ersetzen geeigneter Informationen innerhalb der Einheitendefinition entsprechend der Betriebsumgebung gesehen. Dies geschieht, indem Sie die Anweisungen in der Vorlagendatei wie gewohnt festlegen, aber bestimmte Werte oder Teile von Werten durch Variablenspezifizierer ersetzen.

Im Folgenden werden einige der gebräuchlichsten Bezeichner ersetzt, wenn eine Instanzeinheit mit den relevanten Informationen interpretiert wird:

  • * +% n + *: Überall, wo dies in einer Vorlagendatei erscheint, wird der vollständige resultierende Einheitenname eingefügt.

  • * +% N + *: Dies ist das Gleiche wie oben, jedoch werden alle Escape-Zeichen, wie sie in Dateipfadmustern vorhanden sind, rückgängig gemacht.

  • * +% p + *: Verweist auf das Präfix des Einheitennamens. Dies ist der Teil des Einheitennamens, der vor dem Symbol "+ @ +" steht.

  • * +% P + *: Dies ist das Gleiche wie oben, jedoch mit umgekehrtem Escaping.

  • * +% i + *: Dies verweist auf den Instanznamen, bei dem es sich um den Bezeichner handelt, der in der Instanzeinheit auf das Zeichen "+ @ +" folgt. Dies ist einer der am häufigsten verwendeten Spezifizierer, da garantiert wird, dass er dynamisch ist. Die Verwendung dieses Bezeichners fördert die Verwendung von konfigurationsrelevanten Bezeichnern. Beispielsweise kann der Port, auf dem der Dienst ausgeführt wird, als Instanzkennung verwendet werden, und die Vorlage kann diesen Bezeichner zum Einrichten der Portspezifikation verwenden.

  • * +% I + *: Dieser Bezeichner ist derselbe wie der obige, jedoch mit umgekehrtem Escapezeichen.

  • * +% f + *: Dies wird durch den Namen der nicht entkappten Instanz oder den Präfixnamen ersetzt, dem ein + / + vorangestellt wird.

  • * +% c + *: Dies zeigt die Kontrollgruppe der Einheit an, wobei die standardmäßige übergeordnete Hierarchie von + / sys / fs / cgroup / ssytemd / + entfernt wurde.

  • * +% u + *: Der Name des Benutzers, der für die Ausführung des Geräts konfiguriert ist.

  • * +% U + *: Das Gleiche wie oben, jedoch als numerische + UID + anstelle des Namens.

  • * +% H + *: Der Hostname des Systems, auf dem die Einheit ausgeführt wird.

  • * + %% + *: Hiermit wird ein literales Prozentzeichen eingefügt.

Wenn Sie die oben genannten Bezeichner in einer Vorlagendatei verwenden, gibt "+ systemd +" die richtigen Werte ein, wenn Sie die Vorlage zum Erstellen einer Instanzeinheit interpretieren.

Fazit

Wenn Sie mit + systemd + arbeiten, kann das Verständnis von Units und Unit-Dateien die Administration vereinfachen. Im Gegensatz zu vielen anderen Init-Systemen müssen Sie keine Skriptsprache kennen, um die Init-Dateien zu interpretieren, die zum Booten von Diensten oder des Systems verwendet werden. Die Unit-Dateien verwenden eine relativ einfache deklarative Syntax, mit der Sie den Zweck und die Auswirkungen einer Unit bei der Aktivierung auf einen Blick erkennen können.

Das Aufteilen von Funktionen wie der Aktivierungslogik in separate Einheiten ermöglicht nicht nur die Optimierung der parallelen Initialisierung durch die internen "+ systemd +" - Prozesse, sondern vereinfacht auch die Konfiguration und ermöglicht das Ändern und Neustarten einiger Einheiten, ohne die zugehörigen Verbindungen abzureißen und neu aufzubauen. Wenn Sie diese Funktionen nutzen, können Sie während der Verwaltung flexibler und leistungsfähiger werden.

Related