Wie starte ich Dienste beim Booten in RHEL / CentOS 7 automatisch?

Fragen Sie sich, wie Sie Dienste im Hintergrund oder beim Booten verwalten?


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 aktiviert, aber die Dinge sind anders RHEL 7.

Es wird durch systemd ersetzt. Da es bei großen Linux-Versionen mehr oder weniger der Standardprozessmanager ist, wird sich Systemadministrator, der sich mit anderen Varianten auskennt, 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 systemd verwendet wird, um Hintergrundprozesse damit einzurichten, auszuführen und zu verwalten.

Was ist systemd?

Da jeder Prozess unter Linux transparent sichtbar ist, wollen wir sehen, wo systemd lauert. Auf meinem System wird Folgendes angezeigt:

~ $ 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-activity –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-activity –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-aufgelöst
systemd + 17303 1 0 Nov19? 00:00:00 / lib / systemd / systemd-timesyncd
root 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 Liste wurde als Benutzer root gestartet und hat die PID 1.

Sicher genug, dies war der erste Prozess, den das System beim Booten startete. Begrüßen Sie systemd. ��

Systemd ist also ganz einfach der „Mutter“ -Prozess, der andere Prozesse im System startet, verwaltet und beendet und Informationen zu Protokollierung, Dateisystemstatus usw..

Ein Hinweis zum Namen. Der Name ist in der Tat systemd und nicht System D oder irgendetwas anderes. Das “d” steht für Daemon, einen Standard-Linux-Prozess, der im Hintergrund funktioniert (lauert?) Und keiner Terminalsitzung zugeordnet ist.

Warum RHEL auf systemd umgestellt hat?

Wie bereits erwähnt, ist systemd ein System- und Prozessmanager und ersetzt in RHEL 7 das bekannte Programm Upstart. Warum hat RHEL (Oracle?) Diese Entscheidung getroffen? Dafür gibt es sehr gute Gründe. Schauen wir uns das kurz an.

Parallele Dienstinitialisierung

Im Gegensatz zum SysV-Init-Programm kann systemd Dienste parallel starten. Das Init-Programm startet sie dagegen einzeln. In einer Zeit, in der selbst mobile Geräte über Multi-Core-CPUs verfügen, ist das Fehlen einer parallelen Initialisierung ein großes Problem.

Dynamisches (Hot) Service Management

Wenn Sie bemerkt haben, dass USB-Laufwerke explizit auf früheren Fedora-Systemen bereitgestellt werden müssen, während sie unter Ubuntu und ähnlichen Distributionen automatisch geöffnet werden, ist der Grund systemd. Es ist in der Lage, Live-Änderungen an der Hardware zu erkennen und Dienste nach Bedarf zu beenden / zu starten. Einige können argumentieren, dass dies unnötig ist, aber für viele ist alles, was die kognitive Belastung verringert, sehr willkommen.

Start des verzögerten Dienstes

systemd verkürzt die Startzeiten, da der Start des Dienstes auf den tatsächlichen Zeitpunkt verschoben werden kann. Ein einfaches Beispiel sind Dienste im Zusammenhang mit Netzwerkdateisystemen. Wenn keine Netzwerkfestplatte verfügbar ist, ist es nicht sinnvoll, einen Dienst in Betrieb zu haben.

Schnellere Prozesskommunikation

Die parallelen Funktionen von systemd übertragen sich auf die Kommunikation zwischen Prozessen. systemd bietet parallelen Zugriff auf Sockets und Systembusse und reduziert so die Wartezeiten für Kommunikationsressourcen erheblich.

Automatischer Neustart

Wenn ein Dienst abstürzt, kann systemd dies erkennen und versuchen, ihn neu zu starten. In den meisten Fällen reicht ein einfacher Neustart aus, damit eine Anwendung wieder funktioniert, es sei denn, es gibt grundlegendere Probleme.

Auf jeden Fall erleichtert systemd hier das Leben eines Systemadministrators.

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

Wenn Sie das nörgelnde Gefühl haben, dass systemd nicht alles sein wird, haben Sie Recht. Es gibt einige signifikante Inkompatibilitäten, die RHEL-Systemadministratoren überraschen können. Werfen wir einen kurzen Blick darauf.

Begrenzte Runlevel-Unterstützung

systemd hat eine ziemlich schäbige Anerkennung und Unterstützung für Runlevel. Nicht alle Runlevel werden unterstützt, und für einige Ziele gibt es möglicherweise sogar keine. In solchen Fällen gibt systemd “N” als Antwort auf die Runlevel-Befehle zurück, was bedeutet, dass diesem Ziel kein entsprechender Runlevel zugeordnet ist. Alles in allem rät Red Hat uns, die Runlevel-Befehle nicht (!) Zu verwenden.

Keine benutzerdefinierten Befehle

Dieser wird weh tun. Ein großes Plus bei SysV war die Möglichkeit, benutzerdefinierte Befehle zu definieren, um bessere Funktionen für die Verwaltung von Prozessen bereitzustellen. Bei systemd gibt es keine solche Option, und Sie bleiben bei Start, Stopp, Status, Neustart usw..

Nur für Familien und nicht interaktiv

systemd verfolgt (natürlich) die von ihm gestarteten Prozesse und speichert deren PIDs. Die Herausforderung besteht jedoch darin, dass systemd nicht mit Prozessen umgehen kann, die nicht von systemd gestartet wurden. Außerdem kann ein Benutzer nicht mit einem von systemd gestarteten Prozess interagieren. Die gesamte Ausgabe geht an / dev / null, wodurch alle Hoffnungen, die Sie möglicherweise auf die Erfassung der Ausgabe hatten, effektiv gestoppt werden.

Kein Kontext

Im Gegensatz zu Init-Diensten erben die von systemd gestarteten keine Umgebung von 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 wieder zum Weinen bringt, sind Sie nicht allein. systemd war eine polarisierende Kraft in der Linux-Welt, und das Googeln auf “systemd sucks” wird viel Lesematerial aufdecken. ��

So starten Sie den Dienst automatisch, wenn er nicht verfügbar ist?

Hier ist ein ziemlich häufiger Anwendungsfall in Bereitstellungen. Wir müssen ein Programm in einer Sprache dämonisieren, in der es keine lang laufenden Prozesse gibt: PHP! Nehmen wir an, ich schreibe ein PHP-Skript für eingehende Websocket-Verbindungen (wir haben schließlich eine Chat-App erstellt!) Und das Skript befindet sich unter /home/ankush/chat_server/index.php.

Da Websocket-Verbindungen jederzeit auf den Server zugreifen können, muss dieser Prozess jederzeit aktiv sein und eingehende Verbindungen überwachen. Wir können hier nicht den traditionellen PHP-Lebenszyklus haben, da WebSockets statusbehaftete Verbindungen sind. Wenn das Skript stirbt, ist die Verbindung eine Liste. Wie auch immer, genug auf Websockets; Mal sehen, wie wir dieses Skript über systemd dämonisieren.

Alle systemd-Dienste befinden sich in / etc / systemd / system. Erstellen Sie dort eine Datei, um unser Websocket-Server-Skript zu beschreiben. Angenommen, Sie sind als Root-Benutzer angemeldet.

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

und dann wird das Folgende benötigt.

[Einheit]
Beschreibung = Chat Server Service
Nach = network.target

[Bedienung]
Typ = einfach
User = ankush
ExecStart = php /home/ankush/chat_server/index.php
Neustart = Abbruch

[Installieren]
WantedBy = multi-user.target

Speichern Sie die Datei und der nächste Schritt besteht darin, den systemd-Daemon neu zu laden

# systemctl daemon-reload

und um den soeben erstellten Service zu starten:

# systemctl starte chat_server

Wenn Sie keine Fehler sehen, war es das!

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

  • Der Teil [Einheit] definiert eine neue Serviceeinheit für systemd. In der Systemsprache werden alle Dienste als Diensteinheiten bezeichnet.
  • Die After-Direktive weist systemd (vorhersehbar) an, diesen Dienst erst nach dem Start der Netzwerkdienste zu starten (andernfalls wird die Behandlung von Socket-Verbindungen auf niedrigerer Ebene durchgeführt?!).
  • Der Typ = simple teilt systemd mit, dass dieser Dienst sich nicht selbst verzweigen soll. Mit anderen Worten, es wird immer nur eine Instanz ausgeführt.
  • User = ankush bedeutet, dass dieser Dienst als Benutzer “ankush” ausgeführt wird. Wir könnten dies in “root” ändern, aber aus Sicherheitsgründen wird es dringend empfohlen.
  • Wie Sie sehen, ist ExecStart der tatsächlich auszuführende Befehl.
  • Neustart = bei Abbruch bedeutet, dass der Dienst beim Abbruch neu gestartet werden sollte. In PHP verlieren lang laufende Prozesse Speicher und explodieren schließlich, sodass dies erforderlich ist.
  • Die Direktive WantedBy = teilt systemd mit, zu welchem ​​Ziel (denken Sie an 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 dies aus, um Hintergrundprozesse mit systemd in RHEL 7 auszuführen.

Weitere Option für die Neustartlogik

Im obigen Beispiel habe ich Restart = on-abort konfiguriert, aber dies ist nicht die einzige Option. Es gibt mehr und wählen Sie je nach Anforderung.

  • bei Ausfall – wird neu gestartet, wenn der Exit-Code oder das Signal nicht sauber sind
  • immer – Neustart, wenn ein Signal gefunden wurde, sauber oder unrein
  • anormal – unreines Signal, Watchdog oder Timeout
  • auf Erfolg – nur wenn es durch ein sauberes Signal oder einen Exit-Code gestoppt wurde

Konfigurieren des Dienstes zum Starten beim Booten

Sobald Sie mit dem Skript zufrieden sind und sicherstellen, dass es funktioniert, möchten Sie es als Nächstes so konfigurieren, dass es beim Booten und Starten ausgelöst wird.

Gehen Sie zu / etc / systemd / system und führen Sie den folgenden Aktivierungsbefehl aus (vergessen Sie nicht, den Namen der .service-Datei durch den Namen zu ändern, den Sie haben).

# systemctl enable chat_server.service

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

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

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

Das war einfach! Ist es nicht so??

Hilfe! Ich bin massiv in Upstart investiert. ��

Ich verstehe, dass Sie mir vertrauen, Ihr Fall ist eher die Norm als die Ausnahme. RHEL verwendet Upstart schon so lange, dass sich der Schalter fast wie ein Verrat anfühlt. Aber hey, die Systeme ändern sich ständig und wir sollten uns nicht um Kleinigkeiten streiten. Red Hat erkennt, dass viele Leute mit älteren Versionen nicht weiterkommen und eine erstellt haben Migrationsanleitung auf die Sie sich unbedingt beziehen sollten.

Eine Rettung bei all dem ist, dass systemd mit den SysV-Init-Skripten kompatibel ist. Zum größten Teil müssen Sie also einfach Ihre Dateien verschieben und dieselben Dienste ausführen.

Möchten Sie mehr über Linux Administration und Fehlerbehebung erfahren? Schau dir das an Online Kurs.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map