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 keinen folgenden SIGKILL und nicht 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 diese sein), dann wird es die Dateisystemwurzel dorthin umschalten. Es führt dann den Diensteverwalter von dem (jetzt möglicherweise 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 diese 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 Systemlaufzeit zu der nächsten über die Neustartaktion im Anwendungsraum hinweg weitergegeben werden. Konkret:

    • Dateideskriptoren, die im Dateideskriptorspeicher von Diensten abgelegt sind, die bis zum allerletzten Ende aktiv bleiben, 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.

    • Entsprechend bleiben Dateideskriptoren offen (auch verbindbar), die .socket-Units zugeordnet sind, falls die Units nicht während des Übergangs 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.

    • Service processes may continue to run over the transition, past soft-reboot and into the next session, if they are placed in services that remain active until the very end of shutdown (which again is achieved via DefaultDependencies=no). They must also be set up to avoid being killed by the aforementioned SIGTERM and SIGKILL via SurviveFinalKillSignal=yes, and also be configured to avoid being stopped on isolate via IgnoreOnIsolate=yes. They also have to be configured to be stopped on normal shutdown, reboot and maintenance mode. Finally, they have to be ordered after basic.target to ensure correct ordeering on boot. Note that in case any new or custom units are used to isolate to, or that implement an equivalent shutdown functionality, they will also have to be configured manually for correct ordering and conflicting. For example:

        [Unit]
        Description=Mein überlebender Dienst
        SurviveFinalKillSignal=yes
        IgnoreOnIsolate=yes
        DefaultDependencies=no
        After=basic.target
        Conflicts=reboot.target
        Before=reboot.target
        Conflicts=kexec.target
        Before=kexec.target
        Conflicts=poweroff.target
        Before=poweroff.target
        Conflicts=halt.target
        Before=halt.target
        Conflicts=rescue.target
        Before=rescue.target
        Conflicts=emergency.target
        Before=emergency.target

        [Service]
        Type=oneshot
        ExecStart=sleep infinity

    • Dateisystemeinhängungen können während des Übergangs 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 Weiterlaufen 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[1]. Stellen Sie aber sicher, dass keine Ressource vom Betriebssystem-Dateisystem des Hauptsystems mittels BindPaths= oder ähnlichen Unit-Einstellungen festgehalten wird. Andernfalls verbleibt das alte, ursprüngliche Dateisystem eingehängt, 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.

Note that if a new root file system has been set up on "/run/nextroot/", a soft-reboot will be performed when the reboot command is invoked.

SIEHE AUCH

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

ANMERKUNGEN

1.  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).