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

systemd 255                                                                       SYSTEMD-SOFT-REBOOT.SERVICE(8)