SYSTEMD-SOFT-REBOOT.SERVICE(8)

BEZEICHNUNG
systemd-soft-reboot.service - Neustartaktion im Anwendungsraum

ÜBERSICHT

systemd-soft-reboot.service

BESCHREIBUNG

systemd-soft-reboot.service ist ein Systemdienst, der von soft-reboot.target hereingezogen wird und für die Durchführung einer Neustartaktion rein im Anwendungsraum verantwortlich ist. Beim Aufruf wird er ein Signal SIGTERM an alle noch laufenden Prozesse senden (aber kein folgenden SIGKILL und kein Warten, ob sich die Prozesse beenden). Falls das Verzeichnis /run/nextroot/ existiert (dies kann ein normales Verzeichnis, ein Verzeichnis-Einhängepunkt oder ein Symlink auf einen solchen sein), dann wird es die Dateisystemwurzel dorthin umschalten. Es führt dann den Diensteverwalter von dem (jetzt möglicherweisen neuen) Wurzeldateisystem erneut aus, wodurch eine neue Systemstarttransaktion in die Warteschlange kommt, wie bei einem normalen Systemneustart.

Solch eine reine Neustartaktion im Anwendungsraum erlaubt das Aktualisieren oder Zurücksetzen der Gesamtheit des Anwendungsraums mit minimaler Ausfallzeit, da die Neustartaktion nicht folgende Punkte durchlaufen muss:

    • Die zweite Phase des regulären Herunterfahrens, wie von systemd-shutdown(8) implementiert.

    • Die dritte Phase des regulären Herunterfahrens, d.h. der Rückkehr in den Initrd-Kontext.

    • Die Hardware-Neustart-Aktion

    • Die Firmware-Initialisierung

    • Die Initialisierung des Systemstartprogramms

    • Die Kernel-Initialisierung

    • Die Initrd-Initialisierung

Allerdings hat dies Art des Neustarts auch Nachteile:

    • Die Betriebssystemaktualisierung bliebt unvollständig, da der Kernel nicht zurückgesetzt wird und weiter läuft.

    • Kerneleinstellungen (wie die Einstellungen in /proc/sys/, bekannt auch als »sysctl«- oder /sys/-Einstellungen) werden nicht zurückgesetzt.

Diese Beschränkungen können mit verschiedenen Mitteln adressiert werden, die außerhalb des Umfangs dieser Dokumentation sind, wie beispielsweise dem Live-Patchen des Kernels und hinreichend umfangreichen Dateien in /etc/sysctl.d/.

RESSOURCEN-WEITERGABE

Verschiedene Laufzeit-Betriebssystem-Ressourcen können von einer Laufzeit zu der nächsten über die Neustartaktion im Anwendungsraum hinweg weitergegeben werden. Konkret:

    • Dateideskriptoren, die im Dateideskriptorspeicher eines Dienstes abgelegt sind, der bis zum allerletzten Ende aktiv bleibt, werden zum nächsten Start weitergegeben, wo sie in dem Dateideskriptorspeicher der gleichen Unit abgelegt werden. Damit dies funktioniert, müssen Units DefaultDependencies=no deklarieren (und ein manuelles Conflicts=shutdown.target und ähnliches vermeiden), um sicherzustellen, dass sie nicht normal während der Herunterfahraktion des Systems beendet werden. Alternativ können Sie FileDescriptorStorePreserve= verwenden, um dem Dateideskriptorspeicher zu erlauben, festgehalten zu werden, selbst wenn die Unit heruntergefahren ist. Siehe systemd.service(5) zu Details des Dateideskriptorspeichers.

    • Ähnlich bleiben Dateideskriptoren offen (auch für Verbindungen), die .socket-Units zugeordnet sind, falls die Units nicht während der Transaktion gestoppt werden. (Dies wird durch DefaultDependencies=no erreicht.)

    • Das Dateisystem /run/ bleibt eingehängt und gefüllt und kann zur Übergabe von Zustandsinformationen zwischen Neustartzyklen im Anwendungsraum verwandt werden.

    • Diensteprozesse können über die Transaktion hinweg am Laufen bleiben, falls sie in Diensten abgelegt sind, die bis zum allerletzten Ende des Herunterfahrens aktiv bleiben (was wieder mittels DefaultDependencies=no erreicht wird). Sie müssen auch so eingerichtet werden, dass ihr Beenden durch die zuvor erwähnten SIGTERM-Orgie (gemäß Systemd- und Speicher-Daemons für das Wurzeldateisystem[1]) vermieden wird.

    • Dateisystemeinhängungen können während der Transaktion eingehängt bleiben und komplexe Speichersysteme angehängt, falls sie so konfiguriert wurden, dass sie bis zum allerletzten Ende des Herunterfahrprozesses aktiv bleiben. (Dies wird auch mittels DefaultDependencies=no und dem Vermeiden von Conflicts=umount.target erreicht.)

Obwohl die Weitergabe von Ressourcen von einem weichen Neustartzyklus zum nächsten auf diese Art möglich ist, empfehlen wir nachdrücklich, diese Funktionalität nur restriktiv zu verwenden, da sie zu fragileren Systemen führt, da Ressourcen von Verschiedenen Versionen des Betriebssystems und Anwendungen mit unvorhergesehenen Konsequenzen gemischt werden. Insbesondere wird empfohlen zu vermeiden, es Prozessen zu erlauben, die weiche Neustartaktion zu überleben, da dies bedeutet, dass Code-Aktualisierungen notwendigerweise unvollständig sind und Prozesse typischerweise verschiedene andere Ressourcen festhalten (wie das ihnen zugrundeliegende Dateisystem), wodurch der Speicherverbrauch erhöht wird (da zwei Versionen des Betriebssystems/der Anwendung/des Dateisystems im Speicher verbleiben können). Das Durchlaufen von Prozessen während einer weichen Neustartaktion benötigt die umfassende Abtrennung des Dienstes vom Betriebssystem, d.h. die Minimierung von IPC und die Reduktion der gemeinsamen Verwendung von Ressourcen mit dem Rest des Betriebssystems. Ein möglicher Mechanismus, dies zu erreichen, ist das Konzept des Portablen Dienstes[2]. Stellen Sie aber sicher, dass keine Ressource vom Wurzeldateisystem des Hauptsystems mittels BindPaths= oder ähnlichen Unit-Einstellungen festgehalten wird. Andernfalls wird das alte Wurzeldateisystem im Speicher behalten, solange die Unit läuft.

ANMERKUNGEN

Beachten Sie, dass auch die Programme in /usr/lib/systemd/system-shutdown/ nicht ausgeführt werden, da systemd-shutdown(8) nicht ausgeführt wird.

Beachten Sie, dass systemd-soft-reboot.service (und zugehörige Units) niemals direkt ausgeführt werden sollten. Lösen Sie stattdessen das Herunterfahren des Systems mit Befehlen wie »systemctl soft-reboot« aus.

SIEHE AUCH

systemd(1), systemctl(1), systemd.special(7), systemd-poweroff.service(8), systemd-suspend.service(8), bootup(7)

ANMERKUNGEN

1.  Systemd- und Speicher-Daemons für das Wurzeldateisystem
    https://systemd.io/ROOT_STORAGE_DAEMONS

2.  Portable Dienste
    https://systemd.io/PORTABLE_SERVICES

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 (https://www.gnu.org/licenses/gpl-3.0.html) oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer (debian-l10n-german@lists.debian.org).