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⟩.