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:

Allerdings hat diese Art des Neustarts auch Nachteile:

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:

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[2]. 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 /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

2.

Portable Dienste

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