Hauptseite
Systemadministration
So erstellen Sie die Systemd -Service -Einheit unter Linux

Systemadministration

So erstellen Sie die Systemd -Service -Einheit unter Linux

3982
929
Miriam Bauschke

Obwohl Systemd Gegenstand vieler Kontroversen war, wurden die einige Verteilungen bis zu dem Punkt gegabelt, um es zu beseitigen (siehe Devuan, eine Gabel von Debian, die systemd durch sysvinit ersetzt), ist es am Ende der geworden De-facto Standard Init-System in der Linux-Welt.

In diesem Tutorial werden wir sehen, wie ein Systemd -Dienst strukturiert ist, und wir werden lernen, wie man einen erstellt.

In diesem Tutorial lernen Sie:

Was ist eine Serviceinheit…
Was sind die Abschnitte einer Serviceeinheit?.
Was sind die häufigsten Optionen, die in jedem Abschnitt verwendet werden können.
Was sind die verschiedenen Arten von Service, die definiert werden können.

Softwareanforderungen und Konventionen verwendet

Softwareanforderungen und Linux -Befehlszeilenkonventionen

Kategorie	Anforderungen, Konventionen oder Softwareversion verwendet
System	Eine GNU/Linux -Verteilung, die systemd als Init -System verwendet
Software	systemd
Andere	Root -Berechtigungen sind zur Installation und Verwaltung eines Dienstes erforderlich.
Konventionen	# - erfordert, dass gegebene Linux -Befehle mit Root -Berechtigungen entweder direkt als Stammbenutzer oder mit Verwendung von ausgeführt werden können `sudo` Befehl $ - Erfordert, dass die angegebenen Linux-Befehle als regelmäßiger nicht privilegierter Benutzer ausgeführt werden können

Das Systemd Init -System

Alle wichtigen Verteilungen wie Rhel, Centos, Fedora, Ubuntu, Debian und Archlinux haben Systemd als Init -System übernommen. Systemd ist eigentlich mehr als nur ein Init -System, und das ist einer der Gründe, warum manche Menschen stark gegen das Design sind, was gegen das gut etablierte Unix -Motto widerspricht: „Mach eins und mach es gut.“. Wenn andere Init -Systeme ein einfaches Shell -Skript verwenden, um Dienste zu verwalten, verwendet Systemd seine eigenen .Service Dateien (Einheiten mit dem .Service -Suffix): In diesem Tutorial werden wir sehen, wie sie strukturiert sind und wie man einen erstellt und installiert.

Anatomie einer Serviceinheit

Was ist eine Serviceinheit?? Eine Datei mit der .Service Suffix enthält Informationen zu einem Prozess, der von Systemd verwaltet wird. Es besteht aus drei Hauptabschnitten:

[Einheit]: Dieser Abschnitt enthält Informationen, die nicht speziell mit dem Typ des Geräts zusammenhängen, wie z. B. der Servicebeschreibung
[Service]: Enthält Informationen über den spezifischen Typ des Geräts, einen Dienst in diesem Fall
[Install]: Dieser Abschnitt enthält Informationen zur Installation des Geräts

Lassen Sie uns jeden von ihnen ausführlich analysieren.

Der Abschnitt [Einheit]

Der [Einheit] Abschnitt von a .Service Die Datei enthält die Beschreibung des Geräts selbst und Informationen über das Verhalten und ihre Abhängigkeiten: (Um korrekt zu arbeiten, kann ein Dienst von einem anderen abhängen). Hier diskutieren wir einige der relevantesten Optionen, die in diesem Abschnitt verwendet werden können

Die Option "Beschreibung"

Erstens haben wir das Beschreibung Möglichkeit. Durch die Verwendung dieser Option können wir eine Beschreibung des Geräts bereitstellen. Die Beschreibung wird dann beispielsweise beim Aufrufen der Systemctl Befehl, der einen Überblick über den Status von Systemd zurückgibt. Hier ist es als Beispiel, wie die Beschreibung von httpd Der Service ist auf einem Fedora -System definiert:

[Einheit] Beschreibung = der Apache HTTP -Server

Die Option "After"

Durch Verwendung der Nach Option können wir angeben, dass unsere Einheit nach den Einheiten gestartet werden sollte, die wir in Form einer platz getrennten Liste bereitstellen. Wenn Sie beispielsweise die Dienstdatei erneut beobachten, in der der Apache -Webdienst definiert ist, können wir Folgendes sehen:

Nach = Netzwerk.Ziel-Remote-FS.Ziel NSSS-Lookup.Ziel httpd-init.Service

Die obige Linie weist Systemd an, die Serviceinheit zu starten httpd.Service Nur nach dem Netzwerk, FS-FS entfernen, NSS-Lookup Ziele und die HTTPD-Init-Service.

Angabe harter Abhängigkeiten mit "Erforderlich"

Wie wir oben kurz erwähnt haben, kann eine Einheit (ein Dienst in unserem Fall) von anderen Einheiten (nicht unbedingt „Service“ -Inits) abhängen, um korrekt zu arbeiten: Solche Abhängigkeiten können mit der Verwendung der verwendet werden Erfordert Möglichkeit.

Wenn eine der Einheiten, von denen ein Dienst abhängt, nicht beginnt, wird die Aktivierung des Dienstes gestoppt: Deshalb werden diese aufgerufen harte Abhängigkeiten. In dieser Zeile können wir sehen, wie sie aus der Servicedatei des Avahi-daemon extrahiert werden.Sockeleinheit:

Erfordert = avahi-daemon.Steckdose

Deklarieren Sie "weiche" Abhängigkeiten mit "Wants"

Wir haben gerade gesehen Erfordert Möglichkeit; Wir können auch "weiche" Abhängigkeiten auflisten, indem wir die verwenden Will Möglichkeit.

Was ist der Unterschied? Wie bereits erwähnt, wird der Dienst selbst fehlschlagen, wenn eine „harte“ Abhängigkeit fehlschlägt. Ein Versagen einer „weichen“ Abhängigkeit beeinflusst jedoch keinen Einfluss auf das, was mit der abhängigen Einheit passiert. In dem vorgesehenen Beispiel können wir sehen, wie die Docker.Service Die Einheit hat eine weiche Abhängigkeit von der Docker-Storage-Setup.Service eins:

[Einheit] Wants = Docker-Storage-Setup.Service

Der Abschnitt [Dienst]

Im [Service] Abschnitt von a Service Einheit können wir Dinge als den Befehl angeben, der ausgeführt wird, wenn der Dienst gestartet wird, oder als der Typ des Dienstes selbst. Schauen wir uns einige von ihnen an.

Starten, Stoppen und Nachladen eines Dienstes

Ein Service kann gestartet, gestoppt, neu gestartet oder neu geladen werden. Die Befehle, die bei der Ausführung jeder dieser Aktionen ausgeführt werden sollen [Service] Abschnitt.

Der Befehl, der ausgeführt wird, wenn ein Dienst beginnt ExecStart Möglichkeit. Das an die Option übergebene Argument kann auch der Weg zu einem Skript sein. Optional können wir die Befehle deklarieren, die vor und nach dem Start des Dienstes ausgeführt werden sollen, indem wir die verwenden, indem wir die verwenden ExecStartPre Und ExecStartPost Optionen. Hier ist der Befehl zum Starten des NetworkManager -Dienstes:

[Service] execstart =/usr/sbin/networkManager-no-daemon

In ähnlicher Weise können wir den Befehl angeben, der ausgeführt wird, wenn ein Dienst neu geladen oder gestoppt wird, indem wir die verwenden ExecStop Und Execreload Optionen. Ähnlich wie mit dem, was mit ExecStartPost, Ein Befehl oder mehrere Befehle, die nach gestopptem Prozess gestartet werden sollen, kann mit dem angegeben werden Execstoppost Möglichkeit.

Die Art des Dienstes

Systemd definiert und unterscheidet zwischen unterschiedlichen Diensten, abhängig von ihrem erwarteten Verhalten. Die Art eines Dienstes kann durch die Verwendung der Verwendung definiert werden Typ Option, Bereitstellung eines dieser Werte:

einfach
Gabel
Oneshot
dbus
benachrichtigen

Der Standardtyp eines Dienstes, wenn die Typ Und Busname Optionen werden nicht definiert, aber ein Befehl wird über die bereitgestellt ExecStart Option ist einfach. Wenn diese Art von Dienst festgelegt ist, wurde der Befehl deklariert ExecStart wird als Hauptprozess/Service angesehen.

Der Gabel Typ funktioniert anders ExecStart Es wird erwartet, dass er einen Kinderprozess aufgibt und der Hauptprozess/Service wird. Der übergeordnete Prozess wird erwartet, dass der Startprozess vorbei ist.

Der Oneshot Typ wird als Standard verwendet, wenn die Typ Und ExecStart Optionen sind nicht definiert. Es funktioniert ziemlich ähnlich einfach: Der Unterschied besteht darin, dass der Prozess voraussichtlich seinen Job beenden wird, bevor andere Einheiten gestartet werden. Die Einheit gilt jedoch immer noch als „aktiv“, auch wenn der Befehl beendet ist, wenn der RemaFterexit Die Option ist auf "Ja" gesetzt (der Standard ist "Nein").

Die nächste Art von Service ist dbus. Wenn diese Art von Dienst verwendet wird Dbus, wie in der angegeben Busname Option, die in diesem Fall obligatorisch wird. Für den Rest funktioniert es wie das einfach Typ. Folgende Einheiten werden jedoch erst nach dem Erwerb des DBUS -Namens gestartet.

Ein anderer Prozess funktioniert ähnlich wie einfach, und es ist benachrichtigen: Der Unterschied besteht darin, dass der Dämon eine Benachrichtigung über die sendet sd_notify Funktion. Nur wenn diese Benachrichtigung gesendet wird.

Legen Sie die Prozesszeitüberschreitungen fest

Durch die Verwendung bestimmter Optionen können einige Zeitüberschreitungen für den Dienst definiert werden. Lass uns beginnen mit Neustart: Durch die Verwendung dieser Option können wir den Zeitaufwand (standardmäßig in Sekunden) einrichten, das vor dem Neustart eines Dienstes warten sollte. Ein Timesspan kann auch als Wert für diese Option als „5 -minütige 20er“ verwendet werden. Der Standard ist 100 ms.

Der TimeoutStartSec Und TimeoutStopsec Mit Optionen können die Zeitüberschreitung für ein Service -Startup und Stopp in Sekunden angegeben werden. Im ersten Fall wird nach der angegebenen Zeitüberschreitung des Startprozesses des Daemon nicht abgeschlossen, dass er fehlgeschlagen ist.

Im zweiten Fall, wenn ein Dienst gestoppt werden soll, aber nach dem angegebenen Zeitübergang nicht beendet wird, ist zunächst a Sigterm und dann nach der gleichen Zeit a Sigkill Signal werden darauf gesendet. Beide Optionen akzeptieren auch einen Zeitraum als Wert und können gleichzeitig mit einer Abkürzung konfiguriert werden: Timeoutsc. Wenn Unendlichkeit wird als Wert bereitgestellt, die Zeitüberschreitungen sind deaktiviert.

Schließlich können wir die Grenze für die Zeit, die ein Dienst ausgeführt wird Runtimemaxsec. Wenn ein Dienst diesen Zeitüberschreitungen überschreitet, wird er gekündigt und als fehlgeschlagen angesehen.

Der Abschnitt [Installation]

Im [Installieren] Abschnitt können wir Optionen zur Serviceinstallation verwenden. Zum Beispiel mit der Verwendung der Alias Option können wir eine von Speicherplatz getrennte Liste von Aliase angeben, die für den Dienst verwendet werden sollen ermöglichen).

Ähnlich wie mit dem passiert Erfordert Und Will Optionen in der [Einheit] Abschnitt, um Abhängigkeiten festzulegen, in der [Installieren] Abschnitt können wir verwenden Benötigt von Und Gesucht von. In beiden Fällen deklarieren wir eine Liste von Einheiten, die von der von uns konfigurierenden Abhängigkeiten abhängen. Zum Beispiel:

[Install] wantby = multi-user.Ziel

Mit der obigen Linie erklärten wir, dass die Multi-Benutzer Target hat eine weiche Abhängigkeit von unserem Gerät. In der Systemd -Terminologie enden Einheiten mit dem .Ziel Suffix kann mit dem in Verbindung gebracht werden, was genannt wurde Laufzeiten in anderen Init -Systemen als Sysvinit. In unserem Fall sollte das Multi-User-Ziel, wenn er erreicht ist, unseren Service einschließen.

Erstellen und Installieren einer Serviceeinheit

Grundsätzlich gibt es zwei Orte im Dateisystem, an denen Systemd Service -Einheiten installiert sind: /usr/lib/systemd/system Und /etc/systemd/system. Der erstere Pfad wird für Dienste verwendet, die von installierten Paketen bereitgestellt werden, während der letztere vom Systemadministrator für seine eigenen Dienste verwendet werden kann, die die Standardeinstellungen überschreiben können.

Erstellen wir ein benutzerdefiniertes Dienstbeispiel. Nehmen wir an, wir möchten einen Dienst erstellen, der die Wake-on-LAN-Funktion auf einer bestimmten Ethernet-Schnittstelle (in unserem Fall) bei Beginn der Ethernet-Schnittstelle (ENS5F5. Wir können die verwenden Ethtool Befehl zur Erfüllung der Hauptaufgabe. So könnte unsere Servicedatei aussehen:

[Einheit] Beschreibung = Kraft ENS5F5 Ethernet -Schnittstelle zu 100 Mbit / s erfordert = Netzwerk.Ziel nach = Netzwerk.Ziel [Service] Typ = OneShot Restexit = yes execstart =/usr/sbin/ethtool -s ENS5F5 Wol d execStop =/usr/sbin/Ethtool -s ENS5F5 Wol G [install] suchtby = multi -user.Ziel

Wir setzen eine einfache Beschreibung der Einheit und erklärten, dass der Service von der abhängt Netzwerk.Ziel Einheit und sollte gestartet werden, nachdem es erreicht wurde. Im [Service] Abschnitt Wir setzen den Typ des Dienstes als Oneshot, und angewiesene Systemd, den Dienst als aktiv zu betrachten, nachdem der Befehl ausgeführt wurde, mit dem RemaFterexit Möglichkeit. Wir haben auch die Befehle definiert, die ausgeführt werden sollen, wenn der Dienst gestartet und gestoppt wird. Schließlich in der [Installieren] Abschnitt Wir haben im Grunde erklärt, dass unser Dienst in der enthalten sein sollte Multi-Benutzer Ziel.

Um den Dienst zu installieren, kopieren wir die Datei in die /etc/systemd/system Verzeichnis als Wol.Service, als wir werden damit beginnen:

$ sudo cp Wol.Service/etc/systemd/system && sudo systemctl starten wol.Service

Wir können überprüfen, ob der Dienst mit dem folgenden Befehl aktiv ist:

$ systemctl is-active Wol.Service aktiv

Die Ausgabe des Befehls ist erwartungsgemäß wie erwartet aktiv. Nun zu überprüfen, ob „Wake on lan“ aufgestellt wurde D, Und so ist es jetzt deaktiviert, wir können ausführen:

$ sudo Ethtool ENS5F5 | Grep Wake-on unterstützt Wake-on: PG Wake-on: D

Wenn Sie nun den Service stoppen, sollte das umgekehrte Ergebnis und das wiederum nachwache Wol:

$ sudo systemctl stop Wol.Service && sudo Ethtool ENS5F5 | Grep Wake-on unterstützt Wake-on: PG Wake-on: G

Schlussfolgerungen

In diesem Tutorial haben wir gesehen. Wir haben gelernt, wie man eine Dienstbeschreibung einstellt, ihre Abhängigkeiten definiert und die Befehle deklariert werden, die beim Start, gestoppt oder neu geladen werden sollten.

Da Systemd, wie es oder nicht, zum Standard -Init -System in der Linux -Welt geworden ist, ist es wichtig, sich seiner Art, Dinge zu tun, vertraut zu werden. Die offizielle Dokumentation von Systemd Services finden Sie auf der FreedSktop -Website. Sie könnten auch daran interessiert sein, unseren Artikel über das Verwalten von Diensten mit Systemd zu lesen.