Wie werden Dienste beim Booten in RHEL/CentOS 7 automatisch gestartet?

Sie fragen sich, wie Sie Dienste im Hintergrund oder beim Booten verwalten können?

Der Mechanismus zum Verwalten und Starten von Prozessen beim Booten wurde geändert. Bis RHEL/CentOS 6.x hätten Sie ein Skript in /etc/init.d/ erstellt und mit Hilfe von chkconfig aber die Dinge sind anders auf RHEL 7.

Sie wird ersetzt durch systemd und da er mehr oder weniger der Standard-Prozessmanager der wichtigsten Linux-Versionen ist, Systemverwalter die sich in anderen Geschmacksrichtungen auskennen, werden sich wie zu Hause fühlen. In diesem Artikel werden wir untersuchen, was systemd ist, was die Gründe für den Wechsel waren und wie man die systemd um Hintergrundprozesse einzurichten, auszuführen und zu verwalten.

Was ist systemd?

Da jeder Prozess in Linux transparent sichtbar ist, wollen wir sehen, wo systemd lauert. Auf meinem System erhalte ich die folgende Meldung:

 ~$ ps -ef | grep systemd
root 1 0 0 Nov11 ?        00:01:02 /lib/systemd/systemd --system --deserialize 22
Nachricht+ 768 1 0 Nov11 ?        00:05:46 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root 805 1 0 Nov11 ?        00:10:22 /lib/systemd/systemd-logind
ankush 1132 1 0 Nov11 ?        00:00:00 /lib/systemd/systemd --user
ankush 1176 1132 0 Nov11 ?        00:04:50 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ankush 9772 20029 0 21:11 pts/6 00:00:00 grep --color=auto systemd
systemd+ 17298 1 0 Nov19 ? 00:00:12 /lib/systemd/systemd-resolved
systemd+ 17303 1 0 Nov19 ? 00:00:00 /lib/systemd/systemd-timesyncd
Wurzel 17307 1 0 Nov19 ? 00:00:02 /lib/systemd/systemd-journald
root 18182 1 0 Nov19 ? 00:00:00 /lib/systemd/systemd-udevd

Ich wette, Sie haben es sofort bemerkt. Der erste Prozess in der Auflistung wurde gestartet, als der Benutzer rootund hat die PID 1.

Und tatsächlich war dies der erste Prozess, den das System beim Booten startete. Sagen Sie hallo zu systemd. 🙂

Also, ganz einfach, systemd ist der "Mutter"-Prozess, der andere Prozesse im System startet, verwaltet und beendet und außerdem Informationen über ihre Protokollierung, den Status des Dateisystems usw. liefert.

Noch eine Anmerkung zum Namen. Der Name ist in der Tat systemd und nicht System D oder etwas anderes. Das "d" steht für Daemon, einen Standard-Linux-Prozess, der im Hintergrund arbeitet (lauert?) und nicht mit einer Terminalsitzung verknüpft ist.

Warum hat RHEL zu systemd gewechselt?

Wie wir bereits besprochen haben, systemd ist ein System- und Prozessmanager, der in RHEL 7 das bekannte Programm Upstart ersetzt. Warum hat RHEL diese Entscheidung getroffen? Nun, es gibt sehr gute Gründe dafür, also lassen Sie uns einen kurzen Blick darauf werfen.

Parallele Dienstinitialisierung

Mag die SysV nicht init Programm, systemd ist in der Lage, Dienste parallel zu starten. Die Website init Programm hingegen startet sie nacheinander. In einer Zeit, in der selbst mobile Geräte über Multi-Core-CPUs verfügen, ist das Fehlen einer parallelen Initialisierung ein großer Nachteil.

Dynamische (heiße) Dienstverwaltung

Wenn Sie bemerkt haben, dass USB-Laufwerke auf früheren Fedora-Systemen explizit gemountet werden müssen, während sie sich unter Ubuntu und ähnlichen Distributionen automatisch öffnen, liegt das an systemd. Es ist in der Lage, Live-Änderungen an der Hardware zu erkennen und Dienste je nach Bedarf zu beenden oder zu starten. Manch einer mag argumentieren, dass dies unnötig ist, aber für viele ist alles, was die kognitive Belastung verringert, höchst willkommen.

Aufgeschobener Dienstbeginn

systemd verkürzt die Bootzeiten, da es den Start von Diensten auf den Zeitpunkt verschieben kann, an dem sie tatsächlich benötigt werden. Ein einfaches Beispiel sind Netzwerk-Dateisystem-bezogene Dienste. Wenn keine Netzwerkfestplatte verfügbar ist, macht es keinen Sinn, einen Dienst zu starten und laufen zu lassen.

Schnellere Prozesskommunikation

Die parallelen Fähigkeiten von systemd auf die prozessübergreifende Kommunikation übertragen werden. systemd ist in der Lage, parallelen Zugriff auf Sockets und Systembus zu bieten, wodurch die Wartezeiten der Prozesse auf Kommunikationsressourcen erheblich reduziert werden.

Automatischer Neustart

Wenn ein Dienst ausfällt, systemd kann dies erkennen und versuchen, die Anwendung neu zu starten. In den meisten Fällen reicht ein einfacher Neustart aus, damit eine Anwendung wieder funktioniert, es sei denn, es liegen grundlegendere Probleme vor.

Wie auch immer, systemd macht hier das Leben eines Systemadministrators einfacher.

systemd in RHEL7 - Was ändert sich für Sysadmins?

Wenn Sie das nagende Gefühl haben, dass systemd wird nicht nur Schnickschnack sein, da haben Sie recht. Es gibt einige bedeutende Inkompatibilitäten, die RHEL-Sysadmins überraschen können. Werfen wir einen kurzen Blick darauf.

Begrenzte Runlevel-Unterstützung

systemd hat eine ziemlich dürftige Erkennung von und Unterstützung für Runlevels. Nicht alle Runlevels werden unterstützt, und für einige Ziele gibt es vielleicht sogar gar keine. In solchen Fällen, systemd gibt "N" als Antwort auf die Frage runlevel Befehle, was bedeutet, dass es keinen entsprechenden Runlevel für dieses Ziel gibt. Alles in allem rät uns Red Hat, nicht (!) die runlevel Befehle.

Keine benutzerdefinierten Befehle

Das wird weh tun. Ein großes Plus von SysV war die Möglichkeit, benutzerdefinierte Befehle zu definieren, um bessere Funktionen für die Verwaltung von Prozessen bereitzustellen. Mit systemdgibt es keine solche Option, und Sie müssen sich mit start, stop, status, restart, usw.

Nur für Familien und nicht interaktiv

systemd führt (natürlich) Buch über die von ihm gestarteten Prozesse und speichert deren PIDs. Die Herausforderung ist jedoch, dass systemd kann nicht mit Prozessen umgehen, die nicht von ihm gestartet wurden. Außerdem ist es für einen Benutzer nicht möglich, mit einem Prozess zu interagieren, der von systemd. Alle Ausgaben gehen an /dev/nullund macht damit alle Hoffnungen, die Sie vielleicht hatten, zunichte.

Kein Kontext

Anders als init Dienstleistungen, die von systemd erben keine Umgebung von anderen Benutzern im System. Mit anderen Worten: Informationen wie PATH und andere Systemvariablen sind nicht verfügbar, und jeder neue Prozess wird in einem leeren Kontext gestartet.

Wenn diese Liste von Einschränkungen Sie zum Weinen bringt, sind Sie nicht allein. systemd ist eine polarisierende Kraft in der Linux-Welt, und wenn man nach "systemd sucks" googelt, findet man eine Menge Lesestoff 😉 .

Wie kann man den Dienst automatisch starten, wenn er ausgefallen ist?

Hier ist ein ziemlich häufiger Anwendungsfall bei der Bereitstellung. Wir müssen ein Programm in einer Sprache daemonisieren, die keine langlaufenden Prozesse hat: PHP! Nehmen wir an, ich schreibe ein PHP-Skript, um eingehende Websocket-Verbindungen zu verarbeiten (schließlich haben wir eine Chat-App gebaut!), und das Skript wird unter /home/ankush/chat_server/index.php.

Da WebSocket-Verbindungen jederzeit auf den Server zugreifen können, muss dieser Prozess jederzeit verfügbar sein und eingehende Verbindungen überwachen. Wir können hier nicht den traditionellen PHP-Lebenszyklus verwenden, da WebSockets zustandsabhängige Verbindungen sind, und wenn das Skript stirbt, ist die Verbindung eine Liste. Wie auch immer, genug über WebSockets; lassen Sie uns sehen, wie wir dieses Skript mit Hilfe der folgenden Methode dämonisieren systemd.

Alle systemd Dienste befinden sich in /etc/systemd/system, also legen wir dort eine Datei an, die unser Websocket-Serverskript beschreibt. Angenommen, Sie sind als Root-Benutzer eingeloggt.

# vi /etc/systemd/system/chat_server.service

und dann ist Folgendes erforderlich.

 [Einheit]
Beschreibung=Chat Server Service
Nach=Netzwerk.Ziel

[Dienst]
Typ=einfach
Benutzer=ankush
ExecStart=php /home/ankush/chat_server/index.php
Neustart=bei Abbruch


[Installieren]
WantedBy=multi-user.target

Speichern Sie die Datei und laden Sie im nächsten Schritt den systemd-Daemon neu

 # systemctl daemon-reload

und den gerade erstellten Dienst zu starten:

 # systemctl start chat_server

Wenn Sie keine Fehler sehen, war's das!

Schauen wir uns auch kurz an, was die verschiedenen Direktiven in der Datei bedeuten:

• Die [Unit] Teil definiert eine neue Serviceeinheit für systemd. In der systemd Im Sprachgebrauch werden alle Dienstleistungen als Dienstleistungseinheiten bezeichnet.
• Die After Richtlinie sagt (vorhersehbar) systemd diesen Dienst erst zu starten, nachdem die Netzwerkdienste gestartet wurden (wer soll sonst die untergeordneten Socket-Verbindungen bearbeiten?!).
• Die Type=simple sagt systemd dass dieser Dienst sich nicht selbst aufspalten soll. Mit anderen Worten, es wird immer nur eine Instanz laufen.
• User=ankush bedeutet, dass dieser Dienst unter dem Benutzer "ankush" ausgeführt wird. Wir könnten dies in "root" ändern, aber das ist aus der Sicherheitsperspektive nicht empfehlenswert.
• ExecStartist, wie Sie sehen, der eigentliche Befehl, der ausgeführt werden muss.
• Restart=on-abort bedeutet, dass der Dienst neu gestartet werden soll, wenn er abbricht. In PHP lecken lang laufende Prozesse Speicher und explodieren schließlich, so dass dies notwendig ist.
• Die WantedBy= Richtlinie sagt systemd zu welchem Ziel (z.B. Gruppen) dieser Dienst gehört. Dies führt dazu, dass innerhalb dieses Ziels symbolische Links erstellt werden, die auf den Dienst verweisen.

Im Allgemeinen reicht diese Menge für die Ausführung von Hintergrundprozessen mit systemd in RHEL 7.

Mehr Optionen für die Neustart-Logik

Im obigen Beispiel habe ich Folgendes konfiguriert Restart=on-abort aber das ist nicht die einzige Option. Es gibt noch mehr und man kann je nach Anforderung wählen.

• im Fehlerfall - wird neu gestartet, wenn ein unsauberer Exit-Code oder ein Signal
• immer - Neustart bei Ausfall, sauberem oder unsauberem Signal
• on-abnormal - unsauberes Signal, Watchdog oder Timeout
• auf Erfolgsbasis - nur, wenn sie durch ein sauberes Signal oder einen Exit-Code gestoppt wurde

Konfigurieren des Dienstes zum Starten beim Booten

Wenn Sie mit dem Skript zufrieden sind und sicherstellen, dass es funktioniert, müssen Sie es so konfigurieren, dass es beim Booten und Starten ausgelöst wird.

Gehe zu /etc/systemd/system und führen Sie den folgenden Aktivierungsbefehl aus (vergessen Sie nicht, den Namen der .service-Datei mit dem Ihrer Datei zu ändern)

 # systemctl enable chat_server.service

Sie werden eine Bestätigung sehen, dass ein Symlink erstellt wurde.

 Symlink von /etc/systemd/system/multi-user.target.wants/chat_server.service nach /etc/systemd/system/chat_server.service erstellt.

Starten Sie Ihren Server neu und Sie sollten sehen, dass der Dienst beim Booten startet.

Das war einfach! Nicht wahr?

Hilfe! Ich habe sehr viel in Upstart investiert 🙁.

Ich verstehe Sie, vertrauen Sie mir, Ihr Fall ist eher die Norm als die Ausnahme. RHEL verwendet Upstart schon so lange, dass sich der Wechsel fast wie ein Verrat anfühlt. Aber hey, Systeme ändern sich ständig, und wir sollten uns nicht über Kleinigkeiten streiten. Red Hat hat erkannt, dass viele Leute mit älteren Versionen feststecken, und hat ein Migrationsleitfaden auf die Sie sich unbedingt beziehen sollten.

Der einzige Lichtblick bei all dem ist, dass systemd ist kompatibel mit dem SysV init Skripte, so dass Sie in den meisten Fällen lediglich Ihre Dateien verschieben und die gleichen Dienste zum Laufen bringen müssen.

Möchten Sie mehr über Linux-Administration und Fehlerbehebung erfahren? Besuchen Sie dieses Online-Kurs.