So konfigurieren Sie einen Linux-Dienst so, dass er nach einem Neustart oder Systemabsturz automatisch startet: Teil 2 (Theoretische Erklärungen)

In diesem zweiten Teil des zweiteiligen Tutorials zur Konfiguration von Linux-Diensten für den automatischen Start nach einem Neustart oder Systemabsturz werden wir das Init-System im Detail besprechen. Sie können sich auf Teil 1 der Serie: So konfigurieren Sie einen Linux-Dienst für den automatischen Start nach einem Neustart oder Systemabsturz: Praktische Beispiele hier.

Das aktuelle Tutorial wird sehr theorielastig sein. Daher sollten Sie es als Referenz nutzen, um ein tieferes Verständnis dafür zu erlangen, wie das Init-System in Linux funktioniert. Im ersten Teil dieses Tutorials haben wir einige Code-Snippets und Startup-Skripte geteilt, die das Init-System beim Starten liest. Wir haben auch MySQL als Beispiel verwendet, um zu lernen, wie man einen Linux-Dienst so aktiviert und deaktiviert, dass er nach einem Absturz oder Neustart automatisch startet. Wie Sie im ersten Teil dieses zweiteiligen Tutorials erfahren haben, gibt es drei Init-Systeme, die in verschiedenen Linux-Distributionen verwendet werden: System V, Upstart und Systemd. Sie können sich auf den ersten Teil dieses Tutorials beziehen, um zu verstehen, welche Distribution und Version für die Verwendung eines bestimmten Init-Systems konfiguriert ist.

In diesem Tutorial werden wir den Code erklären, den wir im ersten Teil des Tutorials verwendet haben. Wir werden näher auf die Befehle und die Konfigurationsdateien eingehen, die das Init-System verwendet. Lassen Sie uns beginnen!

Voraussetzungen

Im Fazit des ersten Teils dieses zweiteiligen Tutorials haben wir erwähnt, dass Sie die drei Testserver in Betrieb halten sollten. Wenn Sie sie gelöscht haben, können Sie zurückgehen und sie neu erstellen. Dies wird Ihnen helfen, dem Tutorial zu folgen. Die drei Testserver, die Sie haben sollten, sind:

• Ubuntu 9.04 und früher oder Debian 6 x64 (wir werden dies verwenden, um das System V-Init-System zu demonstrieren)
• Ubuntu 14.04 x64 (wir werden dies verwenden, um Upstart zu demonstrieren). Hier ist ein Tutorial zur einfachen Einrichtung Ihres Ubuntu-Servers.
• CentOS 7 x64 (wir werden dies verwenden, um Systemd zu demonstrieren).

Sie sollten auf jedem der Server, die Sie zum Ausführen der Befehle verwenden, einen Benutzer mit sudo-Rechten haben. Dieses Tutorial zur Konfiguration der Linux-sudoers-Datei kann Ihnen als Anleitung dienen.

Hinweis: Die Befehle in diesem Tutorial greifen in Systemdienste ein. Daher sollten Sie sie nicht auf einem produktiven Live-Server anwenden.

Runlevels

Ein Runlevel ist eine Betriebsebene, die den aktuellen Zustand eines Linux-Systems im Verhältnis zu den verfügbaren Diensten beschreibt. Das Konzept stammt aus dem System V-Init. Wenn das Linux-System hochfährt, initialisiert es den Kernel, wechselt in einen Runlevel und führt das diesem Runlevel zugeordnete Startup-Skript aus. Sie können beim Start nur einen Runlevel ausführen.

Andere Beispiele für Runlevel sind der Herunterfahrzustand, der Neustartmodus, ein Einzelbenutzermodus usw. Jede Ebene bestimmt, welche Dienste in diesem Zustand ausgeführt werden sollen. Einige Dienste können auf mehr als einer Ebene ausgeführt werden, andere nicht.

Es gibt sieben Runlevel: von 0 bis 6. Unten finden Sie eine Definition der sieben Runlevel:

• Runlevel 0: Herunterfahren des Systems
• Runlevel 1: Einzelbenutzer- und Rettungsmodus
• Runlevel 2, 3, 4: Mehrbenutzer- und Textmodus mit aktiviertem Netzwerk
• Runlevel 5: Mehrbenutzer-, netzwerkfähiger und grafischer Modus
• Runlevel 6: Systemneustart

Runlevel werden nicht unbedingt nacheinander ausgeführt. Die Runlevel 2, 3 und 4 variieren je nach der von Ihnen verwendeten Linux-Distribution. Sie können Runlevel 4 in einigen Distributionen implementieren und in anderen nicht. Wenn Sie einen Dienst für den automatischen Start aktiviert haben, wie in Teil eins erklärt, haben Sie ihn tatsächlich zu einem Runlevel hinzugefügt. In System V startet das Betriebssystem mit einem bestimmten Runlevel, und während des Startvorgangs versucht es, alle diesem Runlevel zugeordneten Dienste zu starten. Runlevel sind in Systemd Ziele (Targets), die wir im Abschnitt über Systemd besprechen werden.

Init und PID 1

Das Init-System ist der allererste Prozess, der ausgeführt wird, wenn ein Linux-System hochfährt und der Kernel in den Speicher geladen wird. Es übernimmt verschiedene Aufgaben, darunter die Bestimmung, wie ein Benutzerprozess oder Systemdienst geladen wird, in welcher Reihenfolge und ob er automatisch starten soll. In jeder Linux-Distribution wird jeder Prozess durch eine Prozess-ID (PID) identifiziert, und Init hat die PID 1. Es ist der Elternprozess aller anderen Prozesse, die nacheinander beim Hochfahren des Systems starten.

Geschichte von init

Das Init-System in den neueren Linux-Distributionen ist eine Verbesserung des Originals. Die frühesten Versionen von Linux-Distributionen verwendeten System V init, das in ähnlicher Weise in Unix-Systemen verwendet wurde. Im Zuge der Weiterentwicklung von Linux wurde der Upstart-Init-Daemon implementiert – dieser wurde von Ubuntu entwickelt. Heute (zum Zeitpunkt der Erstellung dieses Tutorials, 2021) haben wir den Systemd-Init-Daemon – dieser wurde zuerst von Fedora implementiert. Da sich Linux-Systeme ständig weiterentwickeln, wird es in Zukunft vielleicht ein neueres Init-System geben. In diesem Tutorial werden wir diese drei besprechen: System V, Upstart und Systemd.

Neuere Linux-Versionen sind standardmäßig mit dem Systemd-Init-System ausgestattet. Die älteren Init-Systeme wurden jedoch aus Gründen der Abwärtskompatibilität beibehalten. Es gibt verschiedene Implementierungen von System V, die Sie in anderen Linux-Varianten verwenden können. Beispielsweise verwendet FreeBSD, eine UNIX-Variante, BSD-init. Ältere Versionen von Debian verwenden SysVinit. Beide stammen von System V ab.

Die Art und Weise, wie jede Version des Init-Daemons Dienste verwaltet, ist unterschiedlich. Die in jeder Version hinzugefügten Verbesserungen zielten auf ein robustes Dienstverwaltungstool ab, das alles bewältigen kann, was ein Linux-System an Diensten, Geräten, Ports und anderen Ressourcen benötigt. Es bestand Bedarf an einem leistungsstarken System, das Ressourcen parallel laden und sich nach einem Systemabsturz elegant erholen konnte.

System V Init-Sequenz

System V verwendet eine inittab-Datei, um Initialisierungsanweisungen zu speichern. Upstart behält die inittab-Datei aus Gründen der Abwärtskompatibilität bei. Hier ist der System V-Startablauf:

• Das Init-System stammt aus der Binärdatei /sbin/init.
• Sobald das Init-System in den Speicher geladen ist, liest es seine erste Datei unter /etc/inittab.
• Einer der Einträge in dieser Datei bestimmt den Runlevel, in den der Rechner booten soll. Wenn beispielsweise der Wert für den Runlevel als 5 angegeben ist, bootet Linux im grafischen Mehrbenutzermodus mit aktiviertem Netzwerk (üblich bei Distributionen, die für den Desktop-Einsatz konzipiert sind). Der hier angegebene Runlevel wird als Standard-Runlevel bezeichnet, da er immer verwendet wird.
• Anschließend sucht das Init-System weiter in der Datei /etc/inittab und liest, welche Init-Skripte es für diesen Runlevel ausführen muss.

Indem das Init-System herausfindet, welche Skripte für einen bestimmten Runlevel ausgeführt werden müssen, ermittelt es, welche Dienste es starten muss. In diesen Init-Skripten konfigurieren Sie normalerweise das Startverhalten für einzelne Dienste, so wie wir den MySQL-Dienst im ersten Teil dieses Tutorials konfiguriert haben.

Struktur der System V Init-Skripte

In diesem Abschnitt werden wir uns die Init-Skripte im Detail ansehen. System V-Konfigurationsdateien oder Init-Skripte steuern die Dienste. Init-Skripte initialisieren einen Dienst, daher der Name Init-Skript.

Jeder Dienst hat sein eigenes Init-Skript. Beispielsweise steuert das MySQL-Init-Skript den MySQL-Server. Anwendungsanbieter stellen die Init-Skripte für ihre jeweilige Anwendung bereit, während native Linux-Dienste mit der Installation des Betriebssystems geliefert werden. Wenn Sie eine benutzerdefinierte Anwendung erstellen, können Sie dafür auch Ihre eigenen benutzerdefinierten Init-Skripte erstellen.

Um einen Dienst wie den MySQL-Server zu starten, wird zuerst sein Binärprogramm in den Speicher geladen. Je nach Konfiguration läuft das Programm im Hintergrund weiter, um Client-Verbindungen anzunehmen. Das Init-Skript des Dienstes übernimmt das Starten, Stoppen oder Neuladen der Binäranwendung. Init-Skripte in System V sind Shell-Skripte. Ein anderer Name für sie ist rc-Skripte (Run Command).

System V Verzeichnisstruktur

Das übergeordnete Verzeichnis für Init-Skripte ist das Verzeichnis /etc. Das Verzeichnis /etc/init.d ist das eigentliche Verzeichnis für die Init-Shell-Skripte. Die Skripte sind symbolisch mit den rc-Verzeichnissen verknüpft.

Es gibt mehrere rc-Verzeichnisse innerhalb des Verzeichnisses /etc, die jeweils eine Nummer im Namen tragen. Die Nummern stehen für verschiedene Runlevels. Wenn Sie den Inhalt des Verzeichnisses auflisten, sehen Sie Namen wie /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, etc.

Wenn Sie sich den Inhalt der einzelnen rc-Verzeichnisse ansehen, werden Sie Dateien sehen, die mit K oder S in ihrem Dateinamen, gefolgt von zwei Ziffern. Diese Dateien enthalten symbolische Links, die auf die eigentlichen Init-Shell-Skripte des tatsächlichen Programms verweisen. Die Buchstaben K und S sind Abkürzungen: K bedeutet Kill oder Stop, während S für Start steht. Die beiden Ziffern in den Dateinamen stehen für die Reihenfolge der Ausführung. Wenn Sie eine Datei namens K05script_name, wird sie vor einer Datei namens K09script_name.

Systemstart

Fahren wir mit der Startsequenz fort und sehen wir uns an, wie die Init-Skripte aufgerufen werden.

Die S- und K-Skripte werden nicht direkt vom Init-System aufgerufen. Vielmehr werden sie von einem anderen Skript aufgerufen: dem /etc/init.d/rc-Skript. Die /etc/inittab-Datei weist den Init-Daemon an, in welchem Runlevel das System standardmäßig starten soll. Abhängig vom angegebenen Runlevel ruft eine Zeile in der /etc/inittab-Datei das Skript /etc/init.d/rc auf und übergibt den Standard-Runlevel als Parameter. Unter Verwendung dieses Parameters ruft das Skript die Dateien unter dem entsprechenden Verzeichnis /etc/rcN.d auf, wobei N den Runlevel bezeichnet. Wenn der Server beispielsweise mit Runlevel 5 startet, werden die entsprechenden Dateien unter dem Verzeichnis /etc/rc5.d aufgerufen.

Innerhalb des rc-Verzeichnisses werden alle K-Skripte numerisch mit dem Argument stop ausgeführt, während alle S-Skripte in ähnlicher Weise mit dem Argument start ausgeführt werden. Die entsprechenden tatsächlichen Init-Shell-Skripte für das Programm, auf das die Dateien unter /etc/rcN.d verweisen, werden jeweils mit den Parametern stop und start aufgerufen.

Einfach ausgedrückt: Wann immer ein Linux-System in einen bestimmten Runlevel eintritt oder dorthin wechselt, werden bestimmte Skripte ausgeführt, um einige Dienste zu stoppen, während andere ausgeführt werden, um andere Dienste zu starten. Dieser Prozess stellt sicher, dass jeder Prozess, der in einem bestimmten Linux-Zustand nicht ausgeführt werden soll, gestoppt wird und jeder Prozess, der ausgeführt werden soll, automatisch gestartet wird.

Automatischer Start unter System V

Wenn Sie einen Dienst so aktivieren, dass er beim Booten automatisch startet, ändern Sie direkt das Init-Verhalten. Wenn Sie beispielsweise einen Dienst so konfigurieren, dass er im Runlevel 2 automatisch startet, erstellt der Init-Prozess die entsprechenden symbolischen Links im Verzeichnis /etc/rc2.d. Um Ihnen das Verständnis zu erleichtern, werden wir dies an einem Beispiel erklären.

System-V-Beispiel

Um Ihnen ein praktisches Beispiel zu geben, verwenden wir die MySQL-Dienstkonfiguration aus Teil 1. Melden Sie sich daher mit Ihrem Sudo-/Root-Benutzer über SSH (oder Putty, wenn Sie Windows verwenden) auf dem Debian 6 VPS an und fahren Sie mit den folgenden Schritten fort.

Schritt 1: Öffnen und Überprüfen der inittab-Datei

Geben Sie zunächst den folgenden Befehl ein, um den Inhalt der inittab-Datei im Terminal anzuzeigen:

Der Inhalt der Datei sollte in etwa so aussehen:

Die Zahl 2 bezeichnet den Runlevel, mit dem das System startet. In diesem Fall ist Runlevel 2 der Standard, daher startet dieses Debian-System im Runlevel 2 im Mehrbenutzer-Textmodus. Sie können den folgenden Befehl ausführen, um dies zu bestätigen:

Die Ausgabe sieht in etwa so aus:

Schritt 2: Überprüfen der rc-Verzeichnisse

Führen Sie als Nächstes den folgenden Befehl aus, um die rc-Verzeichnisse aufzulisten:

Hier ist ein Screenshot der Ausgabe:

Wie wir bereits in der inittab-Datei gesehen haben, ist das System so konfiguriert, dass es im Runlevel 2 startet, weshalb die Skripte unter /etc/rc2.d beim Systemstart ausgeführt werden. Sie können den Inhalt dieses Verzeichnisses mit folgendem Befehl auflisten:

Wie Sie der Ausgabe entnehmen können, handelt es sich bei den Dateien lediglich um symbolische Links, die auf die tatsächlichen Skriptdateien unter /etc/init.d verweisen. Hier ist ein Ausschnitt der Ausgabe:

In diesem Verzeichnis gibt es keine K-Skripte, sondern nur S-Skripte (Start). Die Skripte starten die hier verknüpften Dienste, wie rsync. Sie können auch den mysql-Dienst sehen, der aufgelistet ist und den wir im nächsten Unterthema besprechen.

Schritt 3: Überprüfen des Init-Skripts

Wenn ein Dienst installiert wird, der mit System V kompatibel ist, erstellt er ein Shell-Skript im Verzeichnis /etc/init.d. Sie können die Verfügbarkeit des MySQL-Shell-Skripts überprüfen, indem Sie den folgenden Befehl eingeben:

Es zeigt die folgende Ausgabe:

Die Datei ist ziemlich groß. Sie können den folgenden Befehl eingeben, um ihren Inhalt anzuzeigen:

Schritt 4: Verwendung von chkconfig oder sysv-rc-conf

Chkconfig ist ein Befehl, den Sie in RHEL-basierten Distributionen wie CentOS verwenden können, um System-V-kompatible Dienste zu aktivieren oder zu deaktivieren. Sie können ihn auch verwenden, um installierte Dienste und ihre jeweiligen Runlevel aufzulisten. Hier ist der Befehl dafür (funktioniert auf CentOS):

In Debian-Distributionen existiert ein solches Dienstprogramm nicht nativ. Das update-rc.d in Debian-Systemen installiert und entfernt nur Dienste aus Runlevels. Es ist ein benutzerdefiniertes Tool verfügbar, mit dem Sie die chkconfig-Funktionalität auf Debian-Systeme bringen können. Geben Sie den folgenden Befehl ein, um es zu installieren:

Sobald es installiert ist, können Sie den folgenden Befehl ausführen, um das Runlevel-Verhalten für verschiedene Dienste anzuzeigen:

Die Ausgabe dieses Befehls ist in einer Tabelle formatiert, die links den Dienstnamen und das Runlevel zeigt, unter dem der Dienst ausgeführt wird:

Das X zeigt das Runlevel an, unter dem der Dienst ausgeführt wird. Mit diesem Tool können Sie einen Dienst für ein Runlevel mithilfe der Pfeiltasten und der Leertaste aktivieren oder deaktivieren. Um das Tool zu beenden, drücken Sie Q.

Schritt 5: Testen des MySQL-Startverhaltens beim Systemstart

Aus dem obigen Screenshot können Sie ersehen, dass der mysql-Dienst in den Runlevels 2,3,4,5 aktiviert ist. Sie können MySQL mit dem folgenden Befehl deaktivieren:

Die Ausgabe sieht wie folgt aus. Beachten Sie, dass der Dienst für alle Runlevels gestoppt wurde:

Führen Sie den folgenden Befehl aus, um den Inhalt des Verzeichnisses anzuzeigen:

Sehen Sie sich die mysql-Zeile in der folgenden Ausgabe an:

Die Ausgabe zeigt, dass sich der Symlink in K geändert hat, was Kill (Stoppen) bedeutet. Daher startet MySQL standardmäßig nicht automatisch im Runlevel 2. Wann immer Sie einen Dienst in System V aktivieren oder deaktivieren, passiert Folgendes. Solange ein S-Skript (Start) im Standard-Runlevel-Verzeichnis für einen Dienst vorhanden ist, startet der init-Daemon diesen Dienst beim Systemstart.

Um den Dienst wieder zu aktivieren, geben Sie den folgenden Befehl ein:

Schritt 6: Testen des MySQL-Startverhaltens nach einem Systemabsturz

In diesem Abschnitt besprechen wir, wie System V mit Dienstabstürzen umgeht. Sie können dieses Wissen nutzen, um das Verhalten Ihrer benutzerdefinierten Dienste nach einem Absturz zu konfigurieren.

Im ersten Teil dieses Tutorials hatten wir eine Änderung an der Datei /etc/inittab vorgenommen, damit MySQL nach einem Absturz automatisch neu startet. Wir haben die folgende Zeile hinzugefügt, um dieses Verhalten zu aktivieren:

Wir können dieses Verhalten durch einige Tests überprüfen. Starten Sie zuerst Ihren VPS neu, indem Sie den folgenden Befehl eingeben:

Überprüfen Sie nach dem Neustart, mit welchen Prozess-IDs mysql_safe and mysqld ausgeführt werden. Geben Sie den folgenden Befehl ein, um die Prozess-IDs abzurufen:

Die erhaltene Ausgabe war:

Notieren Sie sich die Prozess-IDs. In unserem Fall waren es 1836 und 186338. Simulieren Sie nun einen Absturz, indem Sie den Prozess mit dem Schalter -9 beenden, indem Sie den folgenden Befehl eingeben. Denken Sie daran, Ihre Prozess-IDs einzusetzen:

Überprüfen Sie nach einigen Minuten den Status von MySQL, indem Sie den folgenden Befehl ausführen:

Die Ausgabe zeigt an, dass MySQL läuft, was bedeutet, dass es nach dem simulierten Absturz neu gestartet wurde. Wenn Sie den Befehl ps -ef | grep mysql erneut ausführen, werden Sie feststellen, dass sowohl mysqld_safe als auch mysqld-Prozesse laufen, wenn auch mit neuen IDs.

Sie können versuchen, die Prozesse mehrmals zu beenden, und sie werden nach einigen Minuten neu gestartet. Dieses Verhalten wird durch die Zeile ermöglicht, die wir der Datei /etc/inittab hinzugefügt haben. So konfigurieren Sie Dienste in System V so, dass sie nach einem Absturz automatisch neu starten. Um die Syntax noch einmal zu sehen, werfen Sie einen Blick auf Teil 1 dieses Tutorials.

Einige benutzerdefinierte Dienste weisen möglicherweise Fehler auf und können nach mehreren Versuchen nicht neu gestartet werden. Der Init-Daemon versucht, einen Dienst neu zu starten, aber wenn dies innerhalb von zwei Minuten mehr als zehnmal fehlschlägt, deaktiviert das Linux-System den Dienst für bis zu 5 Minuten. Dies trägt dazu bei, das System stabil zu halten und sicherzustellen, dass Systemressourcen nicht für abstürzende Dienste verschwendet werden. Es ist ratsam, Ihre Systemprotokolle zu überprüfen, um Probleme mit Ihren benutzerdefinierten Anwendungen zu identifizieren, die behoben werden müssen.

Einführung in Upstart

Das System-V-Init-System war lange Zeit von entscheidender Bedeutung für Linux-Distributionen. Doch wie es in der Technologie üblich ist, entwickelt sie sich ständig weiter. Das Linux-Ökosystem ist dank der Unterstützung der Open-Source-Community enorm gewachsen. System V lädt Jobs und Dienste serialisiert, was Komplexität mit sich bringt und Zeit in Anspruch nimmt. Darüber hinaus führte die Einführung moderner, steckbarer Speichermedien, für die System V nicht ausgelegt war, zu dem Bedarf an einem anderen Init-System.

Die Entwickler bei Ubuntu begannen mit der Arbeit an einem anderen Initialisierungssystem. Dieses Init-System wurde entwickelt, um ein schnelleres Laden des Betriebssystems zu ermöglichen, eine saubere Bereinigung abgestürzter Dienste zu gewährleisten, die Abhängigkeiten zwischen Systemdiensten vorhersehbar zu halten und steckbare Speichermedien zu berücksichtigen. Der Upstart-Daemon war geboren.

Upstart-Init bietet gegenüber System-V-Init folgende Vorteile:

• Upstart lädt Dienste nicht wie System V nacheinander, was die Bootzeit des Systems verkürzt.
• Es ist so konzipiert, dass es abgestürzte Dienste besser handhaben kann, mit einer sauberen Bereinigung und einem Neustart des Dienstes.
• Upstart verwendet ein flexibles Ereignissystem, um die Handhabung von Diensten in verschiedenen Zuständen anzupassen.
• Das Init vermeidet die komplexen Shell-Skripte zum Laden und Verwalten von Diensten wie in System V. Upstart verwendet einfache Konfigurationsdateien, die leicht zu verstehen und zu ändern sind.
• Upstart wurde im Hinblick auf Abwärtskompatibilität entwickelt. Das Skript /etc/init.d/rc wird weiterhin ausgeführt, um native System-V-Dienste zu verwalten.
• Es vermeidet redundante symbolische Links, die alle auf dasselbe Skript verweisen.

Upstart-Ereignisse

Upstart ist ereignisbasiert, sodass demselben Dienst mehrere Ereignisse zugeordnet werden können. Diese ereignisbasierte Architektur sorgt für eine flexible Dienstverwaltung. Jedes Ereignis kann ein für das Ereignis spezifisches Shell-Skript aufrufen.

Zu den Upstart-Ereignissen gehören:

• Starten
• Gestartet
• Stoppen
• Gestoppt

Zwischen einem Ereignis kann sich ein Dienst in verschiedenen Zuständen befinden, unter anderem:

• Wartend
• Pre-start
• Startend
• Post-start
• Laufend
• Pre-stop
• Stoppend
• Post-stop

Upstart-Init kann so konfiguriert werden, dass für jeden dieser Zustände Aktionen ausgeführt werden, was sein flexibles Design ausmacht.

Upstart-Init-Startsequenz

Das Upstart-Init führt beim Start das Skript /etc/init.d/rc aus, genau wie System V. Dieses Skript führt alle System-V-Init-Skripte normal aus, um die Abwärtskompatibilität zu gewährleisten.

Upstart-Konfigurationsdateien befinden sich im Verzeichnis /etc/init, daher sucht es standardmäßig dort und führt die Shell-Befehle aus, die in den Konfigurationsdateien in diesem Verzeichnis enthalten sind.

Upstart-Konfigurationsdateien

Das Upstart-Init-System verwendet Dienstkonfigurationsdateien zur Steuerung von Diensten, im Gegensatz zu den in System V verwendeten Bash-Skripten. Der Namensstandard für diese Dienstkonfigurationsdateien ist service_name.conf.

Die Dateien enthalten Klartext, der in verschiedene Abschnitte, sogenannte Stanzas, unterteilt ist. Jede Stanza beschreibt einen anderen Zustand eines Dienstes und sein Verhalten. Verschiedene Stanzas steuern verschiedene Ereignisse eines Dienstes. Zum Beispiel waiting, pre-start, start, pre-stop, stopping usw.

Eine Stanza enthält Shell-Befehle, was es ermöglicht, für jedes Ereignis jedes Dienstes mehrere Aktionen zu initiieren. Darüber hinaus spezifiziert jede Dienstkonfigurationsdatei die folgenden zwei Dinge:

• In welchen Runlevels der Dienst gestartet und gestoppt werden soll.
• Ob der Dienst neu gestartet werden soll (respawn), wenn er abstürzt.

Upstart-Verzeichnisstruktur

Die Upstart-Dienstkonfigurationsdateien befinden sich im Verzeichnis /etc/init. Verwechseln Sie dies nicht mit /etc/init.d.

Upstart-Beispiel

In diesem Beispiel sehen wir, wie Upstart einen Dienst während des Systemstarts und im Falle eines Absturzes behandelt. Wir werden näher auf die praktischen Beispiele eingehen, die im ersten Teil dieses Tutorials gezeigt wurden.

Schritt 1: Auf dem Ubuntu 14.0.4 Server anmelden

Zuerst verwenden wir zum Testen von Upstart den zweiten VPS, auf dem Ubuntu 14.0.4 läuft. Das liegt daran, dass diese Linux-Distribution Upstart nativ implementiert. Verwenden Sie ssh oder putty, wenn Sie unter Windows arbeiten. Sie müssen sich mit einem Benutzer anmelden, der über Root- oder Sudo-Rechte verfügt. Ich habe einen Benutzer namens hackins, also würde ich mich so anmelden:

Ersetzen Sie dies durch Ihren Root-/Sudo-Benutzer und die öffentliche IP-Adresse Ihres Servers. Drücken Sie dann die Eingabetaste und geben Sie ein Passwort oder eine Passphrase ein.

Schritt 2: Das init- und rc-Verzeichnis untersuchen

Upstart-Konfigurationsdateien werden im Verzeichnis /etc/init gespeichert. Dies ist das Verzeichnis, das Sie beim Erstellen neuer Dienstkonfigurationsdateien verwenden.

Um die Namen der Konfigurationsdateien im Verzeichnis /etc/init aufzulisten, führen Sie folgenden Befehl aus:

Wie Sie an der Ausgabe des obigen Befehls sehen können, laufen viele Dienste unter Upstart. Drücken Sie Q, um less zu beenden.

Wenn Sie Folgendes ausführen, um die Dienstkonfigurationsdateien für System V im rc-Verzeichnis aufzulisten, sehen Sie nur wenige:

Schritt 3: Eine Upstart-Datei untersuchen

Im ersten Teil dieses Tutorials hatten wir eine mysql.conf-Datei verwendet, um mehr über die Serverkonfiguration zu erfahren. Um unser Wissen zu erweitern, verwenden wir eine andere Konfiguration. Die cron-Konfigurationsdatei ist ein guter Kandidat. Geben Sie den folgenden Befehl ein, um die Datei zu öffnen:

Sie sollten eine Ausgabe erhalten, die dem folgenden Screenshot ähnelt:

Das Skript ist ziemlich unkompliziert. Beachten Sie die folgenden wichtigen Felder: start on, stop on, fork, und respawn. Lassen Sie uns definieren, was diese Direktiven tun:

• start on weist Ubuntu an, den cron-Daemon zu starten, wenn das System in die Runlevels 2, 3, 4 oder 5 wechselt. Er wird in den anderen hier nicht angegebenen Runlevels, d. h. 0, 1 oder 6, nicht ausgeführt.
• stop on weist Ubuntu an, einen laufenden Daemon zu stoppen. In diesem Fall gibt es jedoch ein Ausrufezeichen (!), das ein Negationszeichen ist. Das Skript sollte in den Runlevels nach dem Ausrufezeichen nicht gestoppt werden: 2,3,4,5.
• fork-Direktive weist Upstart an, den Prozess von der Konsole zu trennen und im Hintergrund weiterlaufen zu lassen.
• respawn-Direktive weist das System an, cron automatisch neu zu starten, wenn er aus irgendeinem Grund abstürzt.

Drücken Sie Strg+X, um den Editor zu verlassen, ohne etwas einzugeben.

Andere Upstart-Konfigurationsdateien folgen derselben Struktur, mit Stanzas für start, stop und respawn. Einige Konfigurationsdateien enthalten möglicherweise zusätzliche Skriptblöcke für pre-start, pre-stop, post-start und mehr. Diese Codeblöcke teilen dem System mit, was auszuführen ist, wenn sich ein Prozess in einem der definierten Zustände befindet.

Schritt 4: Das Startverhalten des MySQL-Dienstes nach dem Systemstart testen

MySQL ist standardmäßig so eingestellt, dass es nach dem Systemstart automatisch startet. Wir werden versuchen, dies zu deaktivieren und das Verhalten zu beobachten. In Upstart kann ein Dienst deaktiviert werden, indem eine Datei namens service_name.override unter dem Verzeichnis /etc/init/ erstellt wird. Der Inhalt der Datei ist nur ein Wort: manual.

Sehen wir uns an, wie wir diesen Befehl verwenden können, um den MySQL-Dienst zu deaktivieren. Geben Sie den folgenden Befehl ein, um die Datei mit dem Nano-Editor zu öffnen:

Fügen Sie in der geöffneten Datei die folgende Zeile hinzu:

Speichern Sie die Änderungen, indem Sie Strg + O drücken und dann die Eingabetaste drücken. Beenden Sie den Editor, indem Sie Strg + X drücken. Führen Sie den folgenden Befehl aus, um den Server neu zu starten:

Warten Sie einige Minuten und melden Sie sich dann wieder an. Sobald Sie wieder angemeldet sind, testen Sie den Status des MySQL-Dienstes, indem Sie den folgenden Befehl eingeben:

Die Ausgabe zeigt an, dass der Dienst nicht ausgeführt wird:

Dies weist darauf hin, dass MySQL nach dem Systemstart nicht automatisch gestartet wurde. Öffnen Sie als Nächstes die MySQL-Konfigurationsdatei und überprüfen Sie, ob sich die start-Direktive geändert hat:

Die Ausgabe zeigt an, dass nichts geändert wurde:

Das bedeutet: Wenn Ihr Dienst nicht automatisch startet und Sie nur die Konfigurationsdatei des Dienstes (service_name.conf) überprüfen, finden Sie den Fehler möglicherweise nicht. Sie sollten auch überprüfen, ob die Datei service_name.override im Verzeichnis existiert.

Geben Sie den folgenden Befehl ein, um die Override-Datei zu löschen und den MySQL-Dienst wieder zu aktivieren. Starten Sie anschließend den Server neu:

Sobald der Server hochgefahren ist, testen Sie den Status des MySQL-Dienstes erneut:

Es sollte angezeigt werden, dass der MySQL-Dienst automatisch gestartet wurde.

Step 5: Test the MySQL Service Startup Behavior after a System Crash

Standardmäßig startet der MySQL-Dienst nach einem Absturz automatisch neu. Um dieses Verhalten zu unterbinden, bearbeiten wir die Datei mysql.conf . Geben Sie den folgenden Befehl ein, um die Datei mit dem Nano-Editor zu öffnen:

Suchen Sie die respawn-Direktivenzeilen und kommentieren Sie diese wie unten gezeigt mit #:

Führen Sie die folgenden Befehle aus, um den Dienst neu zu starten:

Wir haben die obigen Befehle verwendet, um den Dienst zu stoppen und zu starten, da die Verwendung von initctl restart oder initctl reload hier nicht funktionieren würde. Wenn Sie den Befehl zum Starten des MySQL-Dienstes ausführen, zeigt die Ausgabe eine PID für MySQL an, wie z. B.:

Unsere PID war 1439. Notieren Sie sich als Nächstes, was Sie bei der Ausführung des Befehls erhalten haben, da wir dies im nächsten Schritt verwenden werden. Um einen Absturz zu simulieren, beenden Sie den MySQL-Prozess mit dem folgenden Befehl (denken Sie daran, Ihre PID wie oben beschrieben zu ersetzen):

Um zu überprüfen, ob MySQL nach dem Absturz neu gestartet wurde, warten Sie einige Minuten und geben Sie dann den folgenden Befehl ein:

Die Ausgabe zeigt an, dass MySQL gestoppt ist:

Versuchen Sie, den Status noch einige Male zu überprüfen, um zu sehen, ob sich etwas ändert. Sie werden feststellen, dass MySQL gestoppt bleibt. Dies liegt daran, dass die Dienstkonfigurationsdatei nicht über die Respawn-Direktiven verfügt (diejenigen, die wir auskommentiert haben). Weitere Erläuterungen zur Respawn-Direktive finden Sie in Teil 1 dieses Tutorials.

Warum haben wir Ihnen gezeigt, wie Sie den automatischen Neustart für Dienste nach dem Systemstart oder einem Absturz deaktivieren? Dies dient hauptsächlich zur Fehlerbehebung. Wenn Ihr Dienst beispielsweise startet und ständig abstürzt, möchten Sie ihn möglicherweise deaktivieren, um den Fehler zu beheben und gleichzeitig Ihr System stabil zu halten. Sie können auch verhindern, dass einige alte Dienstkonfigurationen automatisch neu starten, wenn Sie auf eine neue Linux-Distribution aktualisieren, die nativ mit systemd geliefert wird, das im nächsten Abschnitt besprochen wird.

Einführung in Systemd

Systemd ist das neueste Init-System, das in den aktuellsten Linux-Distributionen zu finden ist. Es enthält viele Komponenten, die ein modernes Linux-System ausmachen.

Systemd verwaltet nicht nur die Dienste, sondern das gesamte Linux-System. In diesem Abschnitt konzentrieren wir uns darauf, wie systemd das Verhalten von Diensten nach einem Systemstart oder Absturz steuert.

Systemd ist abwärtskompatibel mit System-V-Init-Skripten und -Befehlen. Wenn Sie also über mit System V konfigurierte Dienste verfügen, laufen diese auch unter Systemd. Die meisten Administrationsbefehle von Upstart und System V wurden so angepasst, dass sie mit Systemd funktionieren. Systemd benennt sich beim Booten in init um. Es existiert eine /sbin/init-Datei als symbolische Verknüpfung zu /bin/systemd.

Systemd-Konfigurationsdateien: Unit-Dateien

Die Systemd-Konfiguration besteht aus Unit-Dateien. Jede Unit-Datei repräsentiert eine Systemressource. Während die anderen beiden Init-Systeme (d. h. System V und Upstart) für die Verwaltung von Diensten eines Linux-Systems zuständig waren, verwaltet Systemd nicht nur die Dienst-Daemons, sondern auch andere Arten von Systemressourcen wie Geräte-Betriebssystempfade, Sockets, Einhängepunkte usw. Unit-Dateien speichern Informationen über die Ressource.

Jede Unit-Datei repräsentiert eine bestimmte Systemressource mit dem Benennungsstil service_name.unit_type. Das bedeutet, dass Sie Dateien wie home.mount, dbus.service, sshd.socket usw. finden. Unit-Dateien sind einfache Textdateien mit einer deklarativen Syntax, die leicht zu verstehen und zu ändern ist.

Verzeichnisstruktur

Der Hauptspeicherort für native Unit-Dateien ist das Verzeichnis /lib/systemd/system/. Von Ihnen erstellte oder von Systemadministratoren benutzerdefiniert erstellte Unit-Dateien sowie andere geänderte native Unit-Dateien werden im Verzeichnis /etc/systemd/system gespeichert.

Wenn eine Unit-Datei mit demselben Namen sowohl im Verzeichnis /lib/systemd/system/ als auch im Verzeichnis /etc/systemd/system existiert, verwendet systemd die Datei unter dem Verzeichnis /etc.

Wenn Sie einen Dienst so aktivieren, dass er beim Systemstart oder einem anderen Target/Runlevel startet, wird ein symbolischer Link für diese Dienst-Unit-Datei in den entsprechenden Verzeichnissen unter /etc/systemd/system erstellt. Unit-Dateien im Verzeichnis /etc/systemd/system sind lediglich symbolische Links zu den Dateien mit ähnlichem Namen im Verzeichnis /lib/systemd/system verzeichnis.

Systemd-Init-Sequenz: Target-Units

Target-Units sind spezielle Arten von Unit-Dateien, die normalerweise die Endung .target haben. Target-Units unterscheiden sich von anderen Arten von Unit-Dateien dadurch, dass sie keine bestimmte Ressource darstellen. Stattdessen repräsentieren sie den Zustand des gesamten Systems zu einem bestimmten Zeitpunkt.

Um dies zu erreichen, gruppieren und starten Target-Units mehrere Unit-Dateien, die Teil eines bestimmten Zustands sind. Obwohl Systemd-Targets und System-V-Runlevels lose verglichen werden können, sind sie nicht dasselbe. Eine Target-Unit-Datei hat einen Namen anstelle einer Nummer. Sie finden beispielsweise so etwas wie multi-user.target anstelle von Runlevel 3 oder reboot.target anstelle von Runlevel 6. Ein Linux-System kann mit multi-user.target booten. In diesem Fall versetzt es den Server im Grunde in Runlevel 2, 3 oder 4, wodurch das System im Multi-User-Textmodus mit aktiviertem Netzwerk gestartet wird.

Der Unterschied liegt darin, wie der Server auf diese Ebene gebracht wird. System V startet Dienste sequenziell. Auf der anderen Seite prüft systemd beim Booten des Systems, ob andere Dienste oder Ressourcen existieren, und bestimmt deren Ladereihenfolge.

Ein weiterer Unterschied zwischen systemd-Target-Units und System-V-Runlevels besteht darin, dass eine Linux-Distribution, die System V verwendet, nur in einem einzigen Runlevel existiert. Wenn Sie den Runlevel ändern, wechselt sie einfach in diesen neuen Runlevel und existiert dort. Auf der anderen Seite können Target-Unit-Dateien inklusiv sein. Darüber hinaus stellt das Aktivieren einer Target-Unit sicher, dass andere Target-Units als Teil davon geladen werden. Wenn Sie beispielsweise ein Linux-System mit einer grafischen Benutzeroberfläche starten, ist das graphical.target aktiviert. Dies wiederum stellt automatisch sicher, dass multi-user.target ebenfalls geladen und aktiviert wird.

Hier ist eine Tabelle, die Runlevels und Targets vergleicht.

Runlevel (System V)	Target-Units (systemd)
Runlevel 0	poweroff.target
Runlevel 1	rescue.target
Runlevel 2,3,4	multi-user.target
Runlevel 5	graphical.target
Runlevel 6	reboot.target

Systemd default.target

In systemd ist default.target das Äquivalent zum Standard-Runlevel in System V. Wir haben gesehen, dass der Standard-Runlevel in System V in der inittab-Datei definiert war. In systemd haben wir die default.target-Datei. Die Standard-Target-Datei wird im Verzeichnis /etc/systemd/system gespeichert. Sie verweist als symbolischer Link auf eine der Target-Unit-Dateien unter /lib/systemd/system. Das Ändern des Standard-Targets bedeutet einfach, einen symbolischen Link neu zu erstellen und den Runlevel des Systems zu ändern.

In System V gab die inittab an, in welchem Verzeichnis Linux die Init-Skripte findet. Dies konnte jedes der rc-Verzeichnisse sein, wie zuvor erklärt. Auf der anderen Seite bestimmt das systemd-Standard-Target die Ressourcen-Units, die beim Booten geladen werden sollen. Alle definierten Units werden geladen. Es werden jedoch nicht alle parallel und nicht alle nacheinander geladen. Das Laden der Ressourcen-Unit hängt von den anderen Ressourcen ab, die sie wants oder requires.

Systemd-Abhängigkeiten: Wants und Requires

In diesem Abschnitt werden wir besprechen, wie Systemd mit Abhängigkeiten umgeht. Wir haben gesehen, dass mit Upstart das parallele Laden von Diensten bei Verwendung von Konfigurationsdateien möglich ist. Wir haben auch besprochen, wie System V Runlevels verwendet, um zu bestimmen, welcher Dienst automatisch gestartet werden soll oder ob gewartet werden soll, bis ein anderer Dienst oder eine andere Ressource verfügbar ist. In ähnlicher Weise können Systemd-Dienste so konfiguriert werden, dass sie in einem oder mehreren Targets geladen werden oder warten, bis ein anderer Dienst oder eine andere Ressource verfügbar ist.

In Systemd startet eine Unit-Datei, die eine andere Unit requires, erst, wenn die erforderliche Unit geladen und aktiv wird. Wenn die erforderliche Unit nicht geladen werden kann, während die erste Unit aktiv ist, wird die erste Unit gestoppt.

Dieses Verhalten sorgt für Systemstabilität. Ein Dienst, der eine bestimmte Ressource (z. B. einen Port) requires, kann so konfiguriert werden, dass er wartet, bis die Ressource verfügbar ist (d. h. der Port geöffnet ist).

Im Gegensatz dazu erlegt eine Unit, die eine andere Unit wants, keine solchen Einschränkungen auf. Sie stoppt nicht, wenn die gewünschte Unit stoppt, während die aufrufende Unit noch aktiv ist. Dies gilt beispielsweise für einige nicht essenzielle Dienste im graphical-target-Modus.

Systemd-Beispiel

Sehen wir uns an, wie wir das Verhalten eines Dienstes unter systemd konfigurieren können.

Schritt 1: Melden Sie sich bei Ihrer VPS-Instanz an

Wir werden MySQL als realen Dienst und CentOS 7 als Server verwenden. Um die Schritte praktisch durchzugehen und die Konzepte zu verstehen, melden Sie sich bei Ihrem CentOS 7 VPS an oder erstellen Sie einen auf CloudSigma. Ein VPS mit CentOS 7, Debian 7 oder 8 oder einer Ubuntu 15-Distribution oder neuer ist für diesen Abschnitt geeignet, da sie alle mit systemd ausgeliefert werden. Melden Sie sich mit dem ssh-Befehl an oder verwenden Sie PuTTY, wenn Sie Windows nutzen:

Schritt 2: Untersuchen der Datei default.target und der Abhängigkeiten

Die Startsequenz von Systemd folgt einer langen Kette von Abhängigkeiten, die wir in diesem Abschnitt im Detail besprechen werden.

• default.target

Die Datei default.target steuert die Dienste, die während eines normalen Systemstarts gestartet werden. Sie können die Standard-Target-Unit-Datei mit dem folgenden Befehl auflisten:

Die Ausgabe sieht in etwa so aus wie auf dem folgenden Screenshot:

Der Screenshot zeigt, dass das Standard-Target als symbolischer Link auf die Datei multi-user.target im Verzeichnis /lib/systemd/system/-Verzeichnis. Dies bedeutet, dass das System standardmäßig unter multi-user.target, was dem Runlevel 3.

• multi-user.target.wants

Um alle Dienste anzuzeigen, die die Datei multi-user.target benötigt, geben Sie den folgenden Befehl ein:

Die Ausgabe enthält viele Zeilen, hier ist ein Ausschnitt:

Wie die Ausgabe zeigt, handelt es sich um symbolische Links, die auf die tatsächlichen Unit-Dateien im Verzeichnis /lib/systemd/system/ verweisen. Wir haben mysqld.service hervorgehoben, um Sie darauf hinzuweisen, dass dieser ebenfalls Teil von multi-user.target ist. Wenn Sie überprüfen möchten, ob ein bestimmter Dienst für den Systemstart konfiguriert ist, können Sie den Befehl für diese Datei anpassen. Beispielsweise können wir die Ausgaben filtern, um den mysql- oder cron-Daemon mit den folgenden Befehlen zu finden:

Die Ausgabe zeigt:

Um das Ergebnis nach dem cron-Daemon zu filtern, geben Sie den folgenden Befehl ein:

Die Ausgabe zeigt:

Neben dem multi-user.target existieren auch andere Arten von Targets, z. B. system-update.target oder basic.target.

Geben Sie den folgenden Befehl ein, um zu sehen, von welchen Targets das multi-user-Target abhängt:

Die Ausgabe zeigt:

Das bedeutet, basic-target muss zuerst geladen werden, damit das System im Modus multi-user.target startet.

• basic-target

Geben Sie den folgenden Befehl ein, um zu sehen, welche anderen Targets das basic.target benötigt:

Die Ausgabe zeigt:

• sysinit.target

Sie können den folgenden Befehl ausführen, um zu sehen, ob es erforderliche Targets für sysinit.target gibt. Die Syntax des Befehls ist dieselbe. Sie können ihn weiter anpassen, um zu sehen, welche Target-Units von einer anderen Target-Unit benötigt werden. Hier ist der Befehl:

Die Ausgabe zeigt, dass es keine erforderlichen Units für sysinit.target gibt. Wir können überprüfen, ob andere Dienste und Targets von angefordert von sysinit.target werden, indem wir folgenden Befehl verwenden:

Die Ausgabe zeigt eine lange Liste von Diensten und Targets, die von sysinit.target angefordert werden. Einen Teil der Ausgabe sehen Sie unten:

Während der Systeminitialisierung mit system4 bleibt das System nicht nur in einem Target. Stattdessen lädt es Dienste in einer abhängigen Weise, während es von einem Target zum anderen wechselt.

Schritt 3: Eine Unit-Datei untersuchen

Sehen wir uns an, wie eine Unit-Datei aussieht. Wir haben die MySQL-Service-Unit-Datei im ersten Teil dieses Tutorials verwendet und werden sie wieder verwenden. Wir können uns jedoch auch eine andere Service-Unit-Datei ansehen – die sshd-Unit-Datei. Geben Sie den folgenden Befehl ein, um die sshd-Konfigurationsdatei zu öffnen:

Unten sehen Sie einen Screenshot, der die Zeilen in der Datei zeigt:

Wie Sie sehen können, machen es die im Dokument skizzierten Codeblöcke einfach, es zu verstehen und bei Bedarf zu ändern. Unten sind einige wichtige Direktiven aufgeführt, die Sie verstehen sollten:

• After – die After-Klausel weist das System an, den Dienst erst zu laden, nachdem die angegebenen Targets und Dienste geladen wurden. In diesem Fall wird der SSHD-Dienst geladen, nachdem das Network-Target und der Keygen-Dienst geladen wurden.
• Wants – die Wants-Klausel zeigt, welche Targets diesen Dienst anfordern. In diesem Fall fordert der ssh-keygen.service den sshd.service an. Wenn sshd jedoch fehlschlägt oder abstürzt, wird der ssh-keygen.service.

Drücken Sie Strg + X, um den Editor zu schließen.

Schritt 4: Startverhalten des MySQL-Dienstes beim Systemstart testen

In diesem Abschnitt zeigen wir Ihnen, wie Sie das Verhalten des MySQL-Dienstes beim Systemstart ändern und testen können. Im vorherigen Abschnitt haben wir gesehen, dass der mysqld.service von multi-user.target angefordert wird. Daher startet er beim Booten automatisch.

Sie können den Dienst deaktivieren, indem Sie den folgenden Befehl ausführen:

Das Ausführen des Befehls zeigt, dass der mysql-Symlink aus dem Verzeichnis /etc/systemd/system/multi-user.target.wants/ entfernt wurde. Um dies zu testen, führen Sie den folgenden Befehl aus, um zu prüfen, ob MySQL immer noch von multi-user.target:

Der Befehl gibt nichts zurück. Wenn Sie versuchen, den Server neu zu starten und den MySQL-Status zu überprüfen, wird er nicht ausgeführt, was bedeutet, dass er beim Booten nicht automatisch gestartet wurde.

Aktivieren Sie nun den Dienst wieder mit dem Befehl:

Die Ausgabe zeigt einen Symlink. Wenn Sie Ihren Server neu starten, sollte MySQL automatisch starten. Das Aktivieren eines Systemd-Dienstes erstellt einen symbolischen Link im wants-Verzeichnis des Standard-Targets. Das Deaktivieren eines Systemd-Dienstes entfernt den symbolischen Link aus dem wants-Verzeichnis.

Schritt 5: Testen des Startverhaltens des MySQL-Dienstes nach einem Dienstabsturz

Standardmäßig startet der MySQL-Dienst im Falle eines Absturzes automatisch neu. Wir können dieses Verhalten in der Systemd-Konfigurationsdatei für MySQL deaktivieren. Werfen wir zunächst einen Blick auf die Datei. Geben Sie den folgenden Befehl ein, um die Datei zu öffnen:

Der folgende Screenshot zeigt die Ausgabe:

Der Wert der Restart-Direktive ist auf on-failure gesetzt. Dies bedeutet, dass der MySQL-Dienst nach unsauberen Exit-Codes, Timeouts oder unsauberen Signalen neu startet. Unten finden Sie eine Tabelle mit einigen der Neustart-Parameter aus der Man-Page.

Neustart-Einstellungen/Exit-Ursachen	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
Sauberer Exit-Code oder Signal		X	X
Unsauberer Exit-Code		X		X
Unsauberes Signal		X		X	X	X
Timeout		X		X	X
Watchdog		X		X	X		X

Die beiden wichtigen Direktiven in einer Systemd-Unit-Datei sind Restart und RestartSec. Sie steuern das Absturzverhalten des Dienstes. Restart gibt an, wann der Dienst neu starten soll, und RestartSec gibt an, wie lange er nach einem Absturz vor dem Neustart warten soll. Um das Neustartverhalten zu deaktivieren, kommentieren Sie die Restart-Direktive aus, indem Sie ein # am Anfang der Zeile hinzufügen, wie gezeigt:

Laden Sie nun den System-Daemon neu und laden Sie dann den mysqld-Dienst mit den folgenden Befehlen neu:

Führen Sie als Nächstes den folgenden Befehl aus, um die Haupt-PID (Main PID) des MySQL-Dienstes zu finden:

Die Haupt-PID für unseren Test war 23809. Notieren Sie sich Ihre, um sie im nächsten Befehl zu verwenden. Simulieren Sie mit dem Befehl kill -9 einen Absturz, indem Sie den Prozess beenden. Denken Sie auch daran, diese durch die Prozessnummer zu ersetzen, die Sie in Ihrem Test erhalten haben:

Wenn Sie den Befehl zur Überprüfung des MySQL-Status ausführen, werden Sie feststellen, dass er nicht aktiv ist und der Neustart fehlgeschlagen ist:

Er bleibt im Zustand „fehlgeschlagen“ (failed), solange die Restart-Direktive in der Konfigurationsdatei mysqld.service auskommentiert ist. Dies simuliert einen Absturz, bei dem ein Dienst stoppt und nicht wieder hochfährt.

Um den Dienst wieder zu aktivieren, können Sie die Konfigurationsdatei mysqld.service bearbeiten, die Restart-Direktive einkommentieren, dann speichern und schließen. Laden Sie, wie zuvor, den Daemon neu und starten Sie den Dienst neu. Dadurch wird der Dienst in seine ursprüngliche Konfiguration zurückversetzt, und er kann nun nach einem Absturz automatisch starten. Das ist schließlich alles, um einen Dienst so zu konfigurieren, dass er nach einem Absturz automatisch startet. Wenn Sie Dienste so konfigurieren möchten, dass sie nach einem Absturz automatisch starten, müssen Sie lediglich die Restart-Direktive (und wenn Sie möchten, können Sie auch die RestartSec-Direktive hinzufügen) unter dem Abschnitt [Service] der Dienst-Unit-Datei hinzufügen.

Fazit

In diesem Tutorial haben wir besprochen, wie Linux Dienste beim Start oder nach einem Absturz handhabt. Um den Linux-Systeminitialisierungsprozess zu verstehen, haben wir die drei Init-Systeme besprochen, die Linux verwendet: System V, Upstart und Systemd. Wir haben ihre Entwicklung besprochen und wie jeder init-Prozess im Verhältnis zum automatischen Starten eines Dienstes nach einem Systemneustart oder -absturz funktioniert.

Da sich sowohl die Init-Daemons als auch die Linux-Distributionen im Laufe der Zeit weiterentwickelt haben, denken Sie daran, die Version der von Ihnen ausgeführten Linux-Distribution zu überprüfen, damit Sie wissen, welchen Init-Daemon Ihr System nativ unterstützt.

Native Linux-Anwendungen und die meisten Anwendungen von Drittanbietern starten bereits nach einem Systemstart oder -absturz automatisch, sodass Sie nichts tun müssen. Das Wissen in diesem Tutorial ist von entscheidender Bedeutung, wenn Sie das Start- und Respawn-Verhalten Ihrer eigenen benutzerdefinierten Dienste konfigurieren oder Fehler bei ständig abstürzenden Diensten beheben.

Viel Spaß beim Computing!