systemctl sendet Anforderungen an einen systemd-Manager. Diese Lektion konzentriert sich auf Systemdienst-Units. Bestätige den genauen Unit-Namen, den Managerbereich, die Abhängigkeiten und die betrieblichen Auswirkungen, bevor du den Zustand änderst.
Init · Lektion 6
Systemd-Ziele
Erfahre, wie du systemd-Dienst-Units untersuchst, überschreibst, validierst, startest, aktivierst und Fehler diagnostizierst.
Eine Dienst-Unit lesen
Eine minimale beispielhafte Unit kann so aussehen:
[Unit]
Description=Example worker
Wants=network-online.target
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]enthält die Beschreibung und Abhängigkeitsbeziehungen.[Service]definiert den Prozesslebenszyklus und dienstspezifisches Verhalten.[Install]teilt Aktivierungsbefehlen mit, welche Aliase oder Abhängigkeitsverknüpfungen sie erstellen sollen; der Abschnitt ist nicht automatisch eine aktive Laufzeitabhängigkeit.
ExecStart= wird standardmäßig nicht durch eine Shell geleitet. Shell-Pipelines, Umleitungen, Variablen und Anführungszeichen verhalten sich nicht wie in einer interaktiven Befehlszeile, sofern nicht absichtlich eine ausdrückliche Shell aufgerufen wird.
Was ist der Hauptzweck von [Install]-Direktiven wie WantedBy=?
Die wirksame Konfiguration untersuchen
Liste geladene Units auf mit:
$ systemctl list-units --type=service
Liste installierte Unit-Dateien und Aktivierungszustände auf mit:
$ systemctl list-unit-files --type=service
Dies sind unterschiedliche Ansichten: Eine Unit-Datei kann aktiviert, aber inaktiv, aktiv, aber deaktiviert, statisch, erzeugt, transient, maskiert oder in einer der Auflistungen nicht vorhanden sein. Untersuche zusammengeführte Anbieter- und Drop-in-Inhalte mit:
$ systemctl cat UNIT.service
$ systemctl show UNIT.service
Was zeigt list-unit-files, das list-units nicht in erster Linie zeigt?
Eine lokale Überschreibung erstellen
Verwende ein Drop-in, statt eine mit einem Paket gelieferte Unit zu bearbeiten:
$ sudo systemctl edit UNIT.service
Nach dem Speichern weist systemctl den Manager bei aktuellen Implementierungen im Rahmen dieses Bearbeitungsablaufs normalerweise an, neu zu laden. Wenn Dateien auf andere Weise geändert werden, führe dagegen Folgendes aus:
$ sudo systemctl daemon-reload
daemon-reload liest Unit-Definitionen neu ein und erstellt Abhängigkeiten erneut. Der Befehl lädt weder Anwendungskonfiguration neu noch startet er laufende Dienste neu. Validiere gegebenenfalls Unit-Syntax und Abhängigkeiten mit systemd-analyze verify und prüfe danach die wirksame zusammengeführte Unit.
Was bewirkt systemctl daemon-reload?
Laufzeitzustand von Diensten
Nachdem du die Dienstkonfiguration validiert und einen Wiederherstellungszugang bewahrt hast:
$ sudo systemctl start peanut.service
$ sudo systemctl stop peanut.service
$ sudo systemctl restart peanut.service
$ sudo systemctl reload peanut.service
reload ist nur erfolgreich, wenn die Unit eine Neuladeaktion definiert oder unterstützt. restart unterbricht den Prozess und kann den Dienst möglicherweise nicht wiederherstellen. Halte für Fernzugriff, Netzwerk, Speicher oder Authentifizierung einen separaten Konsolenzugang bereit und prüfe die Konfiguration, bevor du handelst.
Prüfe Zustand und Protokolle mit:
$ systemctl status peanut.service
$ systemctl is-active peanut.service
$ journalctl -u peanut.service -b
„Active“ ist ein Managerzustand und kein Beweis dafür, dass jeder Anwendungsendpunkt fehlerfrei ist.
Welcher Befehl startet peanut.service jetzt, ohne für sich allein die künftige Aktivierung zu ändern?
Aktivieren, Deaktivieren und Maskieren
Verwalte Verknüpfungen für künftige Abhängigkeiten mit:
$ sudo systemctl enable peanut.service
$ sudo systemctl disable peanut.service
Enable startet die Unit nur, wenn --now hinzugefügt wird. Disable stoppt eine laufende Unit nur, wenn --now hinzugefügt wird. Einer statischen Unit können Installationsmetadaten fehlen, obwohl sie weiterhin als Abhängigkeit einer anderen Unit aktiviert werden kann.
Beim Maskieren wird die Unit mit /dev/null verknüpft. Dadurch wird die gewöhnliche Aktivierung einschließlich der Aktivierung als Abhängigkeit blockiert, bis die Maskierung aufgehoben wird. Dies ist stärker als Deaktivieren und kann abhängige Units beeinträchtigen; prüfe vor der Verwendung die umgekehrten Abhängigkeiten.
Was geschieht mit einem bereits laufenden Dienst nach systemctl disable UNIT ohne --now?
Das Ergebnis des Dienstes überprüfen
Prüfe nach einer Änderung den Prozesszustand, aktuelle Protokolle, lauschende Endpunkte, abhängige Units, den Zustand der Anwendung und – falls sich die Bootaktivierung geändert hat – das Verhalten nach einem kontrollierten Neustart. Verwende je nach Bedarf systemctl is-failed, systemctl list-dependencies und anwendungseigene Prüfungen.
Lektion abgeschlossen
Sie haben Systemd-Ziele abgeschlossen
Du kannst einen systemd-Dienst nun verwalten, ohne Konfiguration, Laufzeit und Aktivierung miteinander zu verwechseln.
Lies
[Unit],[Service]und[Install]entsprechend ihren unterschiedlichen Aufgaben.Vergleiche den Zustand geladener Units mit dem Zustand installierter Unit-Dateien.
Verwende Drop-ins und lade den Manager nach externen Dateiänderungen neu.
Starte, stoppe, lade neu oder starte erst nach Prüfung der Auswirkungen neu.
Behandle Aktivieren, Deaktivieren und Maskieren als getrennte Steuerungen der Dauerhaftigkeit.
Lernfortschritt speichern
Erstellen Sie ein kostenloses Konto, um diese Lektion zu speichern und auf jedem Gerät weiterzulernen.
Kostenloses Konto erstellen