other versions
- buster 2.12-1
- buster-backports 4.10.0-1~bpo10+1
- testing 4.10.0-1
- unstable 4.10.0-1
SYSTEMD.OFFLINE-UPDATES(7) | systemd.offline-updates | SYSTEMD.OFFLINE-UPDATES(7) |
BEZEICHNUNG¶
systemd.offline-updates - Implementierung von Offline-Aktualisierungen in SystemdOFFLINE SYSTEM-AKTUALISIERUNGEN IMPLEMENTIEREN¶
Diese Handbuchseite beschreibt, wie die »offline« Systemaktualisierungen mit Systemd realisiert werden. Unter dem Begriff »offline« Betriebssystemaktualisierungen verstehen wir Paketinstallationen und -aktualisierungen, die ausgeführt werden, ohne dass das System in einen besonderen Systemaktualisierungsmodus gestartet wurde, um Probleme in Bezug auf Konflikte bei Bibliotheken und Diensten, die derzeit laufen, mit denen auf der Platte zu vermeiden. Dieses Dokument wurde vom GNOME Design-Whiteboard[1] inspiriert.Die Logik:
1.Der Paketverwalter bereitet Systemaktualisierungen
vor, indem er alle offline zu aktualisierenden (RPM- oder DEB- oder was auch
immer) Pakete in ein spezielles Verzeichnis /var/lib/system-update (oder ein
anderes Verzeichnis nach Wahl des Paket-/Upgrade-Verwalters)
herunterlädt.
2.Wenn der Benutzer die Aktualisierung bestätigt
hat, wird der Symlink /system-update, der auf /var/lib/system-update (oder wo
auch immer das Verzeichnis mit den Upgrade-Dateien sich befindet) zeigt,
erstellt, und das System wird neu gestartet. Dieser Symlink ist im
Wurzelverzeichnis, da er sehr früh im Systemstartprozess geprüft
werden muss, zu einem Zeitpunkt, an dem /var noch nicht verfügbar
ist.
3.Sehr früh im Systemstartprozess prüft
systemd-system-update-generator(8) ob /system-update existiert. Falls
das der Fall ist, wird (temporär und nur für diesen Systemstart)
default.target auf system-update.target umgelenkt (d.h. ein Symlink angelegt).
Letzteres ist ein besonderes Ziel, das das Basissystem (d.h. sysinit.target,
so dass alle Dateisysteme eingehängt sind, aber nicht viel mehr) und
die Systemaktualisierungs-Units hereinzieht.
4.Das System fährt jetzt fort, in default.target
und damit in system-update.target zu starten. Dieses Ziel zieht alle
Systemaktualisierungs-Units herein. Nur ein Dienst sollte Aktualisierungen
durchführen (siehe den nächsten Punkt) und alle anderen sollten
sich sauber mit einem Rückgabecode »success« und ohne
etwas weiteres durchzuführen beenden. Aktualisierungsdienste sollten
nach sysinit.target angeordnet sein, so dass die Aktualisierung beginnt,
nachdem alle Dateisysteme eingehängt wurden.
5.Im ersten Schritt sollte ein Aktualisierungsdienst
prüfen, ob der Symlink /system-update auf dem vom Aktualisierungsdienst
verwandten Ort zeigt. Falls er nicht existiert oder an einen anderen Ort
zeigt, muss sich der Dienst fehlerfrei beenden. Es ist möglich, dass
mehrere Aktualisierungsdienste installiert sind und mehrere
Aktualisierungsdienste parallel gestartet sind und nur derjenige, der dem
Werkzeug entspricht, das den Symlink vor dem Neustart erstellte, sollte
irgendwelche Aktionen durchführen. Es ist nicht sicher, mehrere
Aktualisierungen parallel durchzuführen.
6.Der Aktualisierungsdienst sollte jetzt seine Aufgabe
erledigen. Falls zutreffend und möglich, sollte er einen
Dateisystemschnappschuss erstellen, dann alle Pakete installieren. Nach dem
Abschluss (unabhängig davon, ob die Aktualisierung gelungen oder
fehlgeschlagen ist) muss die Maschine neu gestartet werden, beispielsweise
durch Aufruf von systemctl reboot. Im Fehlerfall sollte das Skript
zusätzlich auf den alten Dateisystemschnappschuss (ohne den Symlink)
zurückkehren.
7.Das Upgrade-Skript sollte sich nur beenden, wenn die
Aktualisierung abgeschlossen ist. Es wird erwartet, dass der Dienst, der das
Upgrade durchführt, einen Systemneustart auslöst, nachdem er
fertig ist. Falls das system-update.target erfolgreich erreicht wurde, d.h.
alle Aktualisierungsdienste ausgeführt wurden und der Symlink
/system-update immer noch existiert, wird dieser entfernt und als
Sicherheitsmaßnahme die Maschine neu gestartet.
8.Nach einem Neustart, nun dass der Symlink
/system-update verschwunden ist, wird der Generator default.target nicht mehr
umleiten und das System nun wieder in das Standardziel starten.
EMPFEHLUNGEN¶
1.Um für mehr Robustheit zu sorgen, empfehlen
wir, das Aktualisierungsskript mittels eines Symlinks .wants/ in dem
Distributionspaket in system-update.target einzuhängen, statt in
Postinst-Skriptstücken im Paket von systemctl enable
abzuhängen. Für Ihre Aktualisierungsskripte sollten Sie
konkreter eine Datei .service ohne Abschnitt »[Install]«
erstellen und dann einen Symlink der Art
/lib/systemd/system-update.target.wants/foobar.service →
../foobar.service zu Ihrem Paket hinzufügen.
2.Stellen Sie sicher, dass der Symlink /system-update in
Ihrem Aktualisierungsskript so früh wie möglich entfernt wird,
um im Fehlerfall Neustartschleifen zu vermeiden.
3.Verwenden Sie FailureAction=reboot in der
Dienstedatei Ihres Aktualisierungsskriptes, um sicherzustellen, dass
automatisch ein Neustart ausgelöst wird, falls die Aktualisierung
fehlschlägt. FailureAction= stellt sicher, dass die festgelegte
Unit aktiviert ist, falls Ihr Skript sich unsauber beendet (mit einem von Null
verschiedenen Fehler-Code oder einem Signal/Speicherauszug). Falls Ihr Skript
sich erfolgreich beendet, sollten Sie den Systemneustart in Ihrem Code
auslösen, beispielsweise durch den Aufruf Reboot() von logind
oder dem Aufruf von systemctl reboot. Siehe Logind
dbus-API[2] für Details.
4.Der Aktualisierungsdienst sollte
DefaultDependencies=no, Requires=sysinit.target,
After=sysinit.target, After=system-update-pre.target und
explizit alle benötigten Dienste hereinziehen.
5.Es kann wünschenswert sein, immer eine
Hilfs-Unit beim Starten in den offline-updates-Modus zu betreiben, die selbst
keine Aktualisierungen installiert. Um dies zu erledigen, erstellen Sie eine
.service-Datei mit Wants=system-update-pre.target und
Before=system-update-pre.target und fügen Sie einen Symlink auf
diese Datei unter /lib/systemd/system-update.target.wants hinzu..
SIEHE AUCH¶
systemd(1), systemd.generator(7), systemd-system-update-generator(8), dnf.plugin.system-upgrade(8)ANMERKUNGEN¶
- 1.
- GNOME Design-Whiteboard
- 2.
- Logind dbus-API
Ü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 <debian-l10n-german@lists.debian.org>.
systemd 241 |