Rocky und Alma: Welche Updates erfordern einen Reboot?

Welche Updates erfordern unter Rocky Linux und AlmaLinux einen Reboot?

Unter Rocky Linux und AlmaLinux schreibt dnf update neue Dateien auf die Festplatte und beendet den Vorgang dort. Der gestartete Kernel läuft weiter. Jeder Prozess, der bereits eine Bibliothek geöffnet hat, verwendet weiterhin die geöffnete Kopie, weil Linux die alte Datei auf der Festplatte erhält, bis der letzte Prozess, der sie verwendet, beendet wird. Deshalb kann der Rechner null verfügbare Updates melden, obwohl er weiterhin den Code ausführt, den diese Updates ersetzt haben. Das Verhalten ist bei beiden Distributionen identisch, weil beide aus denselben Red-Hat-Quellen neu gebaut werden. Die Wahl zwischen Rocky und Alma hängt daher von Kompatibilitätszusagen und CPU-Unterstützung ab, nicht von etwas, das Sie in diesem Zusammenhang sehen. Die folgenden Befehle wurden auch auf einem CentOS-System verwendet. Das ist kein Zufall: Beide Projekte wurden nach der Stream-Ankündigung von 2020 als CentOS-Ersatz entwickelt.

Welche Updates einen Reboot erfordern und für welche ein Neustart des Dienstes genügt, müssen Sie das System selbst fragen. Der dafür zuständige Befehl ist needs-restarting. Updates werden in drei Stufen eingeteilt. Der Kernel und eine kurze Liste zentraler Pakete erfordern einen vollständigen Reboot. Bei gewöhnlichen Bibliotheksupdates müssen die Dienste neu gestartet werden, die diese Bibliotheken verwenden. Alle übrigen Updates sind in dem Moment angewendet, in dem RPM den Vorgang beendet.

Install needs-restarting

needs-restarting ist ein DNF-Plugin. Das Plugin wird in dnf-plugins-core bereitgestellt, das auf den meisten Rocky- und Alma-Installationen bereits vorhanden ist. Der Befehl /usr/bin/needs-restarting ist ein kleines Wrapper-Skript aus dnf-utils.

sudo dnf install -y dnf-utils
needs-restarting --help

Beide Schreibweisen führen denselben Code aus, weil der Wrapper den DNF-Unterbefehl aufruft:

needs-restarting -r
dnf needs-restarting -r

Beide Pakete stammen aus den eigenen Repositories der Distribution. Sie müssen dafür EPEL oder das CRB-Repository nicht aktivieren.

Bei Rocky Linux 10 und AlmaLinux 10 ist dnf DNF 5. needs-restarting ist dort einer der eigenen Befehle von dnf5-plugins. dnf needs-restarting liefert dort ohne Optionen direkt die Antwort, ob ein Reboot erforderlich ist. -r wird weiterhin akzeptiert. Laut Handbuch hat die Option keine Wirkung und existiert nur, damit DNF-4-Skripte weiterhin funktionieren.

Tier 1: Updates, die einen Reboot erfordern

Führen Sie zuerst die Reboot-Prüfung aus. Sie liest nur die RPM-Datenbank und die Boot-Zeit des Systems. Deshalb ist sie schnell und benötigt keinen root-Zugriff.

needs-restarting -r

Wenn sich seit dem Boot nichts Wichtiges geändert hat, gibt sie zwei Zeilen aus:

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Wenn sich etwas geändert hat, gibt sie Core libraries or services have been updated since boot-up: aus, danach die gefundenen Paketnamen und anschließend:

Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943

Der Exit-Code enthält dieselbe Information: 0 bedeutet, dass kein Reboot erforderlich ist, 1 bedeutet, dass einer erforderlich ist. Gegen diesen Teil richten Sie Ihre Skripte.

if ! needs-restarting -r >/dev/null; then
  logger -t updates "reboot pending on $(hostname -s)"
fi

Exit-Code 1 ist hier eine normale Antwort und kein Fehler. Unter set -e beendet ein nicht abgesichertes needs-restarting -r Ihr Skript an dieser Stelle. Deshalb umschließt das obige Beispiel den Aufruf mit if.

Die Pakete, die die Reboot-Antwort auslösen, stehen in einer kurzen fest codierten Liste im Plugin. In aktuellen Versionen enthält sie kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Ältere Plugin-Versionen enthalten eine etwas kürzere Liste. Prüfen Sie daher Ihre Version, statt dies vorauszusetzen.

Jeder Eintrag steht aus einem klar benennbaren Grund auf dieser Liste. Ein neues kernel-Paket schreibt nur Dateien nach /boot und /lib/modules. Der laufende Kernel kann nicht unter sich selbst ausgetauscht werden. Deshalb ändert sich erst nach dem Boot etwas. Jeder Prozess auf dem System verwendet glibc. „Die betroffenen Dienste neu starten“ würde daher auch einen Neustart von PID 1 bedeuten. Ein Reboot ist dafür die sichere Variante. dbus und dbus-broker übertragen jede Client-Verbindung auf dem System. Wenn Sie den Bus auf einem laufenden System stoppen, fallen die Clients aus, die gerade mit ihm kommunizieren. linux-firmware und microcode_ctl werden beim Boot geladen. Bei einem VPS ändert der Microcode normalerweise nichts, was Sie beobachten können, weil der Hypervisor-Host die physische CPU verwaltet.

Sie können eigene Pakete hinzufügen. Jede .conf-Datei unter /etc/dnf/plugins/needs-restarting.d/ wird als Liste von Paketnamen gelesen, jeweils ein Name pro Zeile. Diese Namen werden der Reboot-Liste hinzugefügt.

echo 'openssl-libs' | sudo tee /etc/dnf/plugins/needs-restarting.d/openssl.conf

Das ist eine Richtlinienentscheidung und keine Fehlerbehebung. Sie sagt: „Wenn sich die TLS-Bibliothek ändert, möchte ich lieber einen Reboot durchführen, als jedes betroffene Service zu ermitteln.“

Woraus der Neustart-Hinweis tatsächlich abgeleitet wird

needs-restarting -r vergleicht Ihre laufende Kernelversion nicht mit dem neuesten installierten Kernel. Es vergleicht Zeitstempel. Für jedes Paket in dieser Kernliste liest es die RPM-Installationszeit aus und vergleicht sie mit dem Zeitpunkt, zu dem das System gestartet wurde. Wenn ein Kernpaket nach dem letzten Start installiert wurde, lautet die Antwort „Neustart erforderlich“. Die Startzeit stammt, sofern verfügbar, über D-Bus aus UnitsLoadStartTimestamp von systemd. Andernfalls wird der spätere Zeitpunkt aus der Änderungszeit von /proc/1 und dem Feld btime in /proc/stat verwendet.

Dieser Mechanismus hat eine wichtige Konsequenz. Wenn Sie einen Kernel installieren, das System neu starten und wegen eines fest vorgegebenen Boot-Standards wieder mit einem älteren Kernel starten, liegt die Installationszeit nun vor der Startzeit und needs-restarting -r bleibt still. Die Ausgabe beantwortet die eigene Frage korrekt. Sie beantwortet jedoch nicht die Frage, die Sie gestellt haben. Prüfen Sie den Kernel separat.

uname -r
rpm -q --last kernel
sudo grubby --default-kernel

Der erste Befehl zeigt, was aktuell ausgeführt wird. Die erste Zeile von rpm -q --last kernel enthält den zuletzt installierten Kernel. grubby --default-kernel zeigt, welchen Kernel der Bootloader beim nächsten Start auswählt. Wenn diese drei Angaben voneinander abweichen, korrigieren Sie den Boot-Standard, bevor Sie einen Rechner neu starten, den Sie nicht über eine Konsole erreichen können.

Tier 2: Updates, die einen Dienstneustart erfordern

Wenn RPM eine gemeinsam verwendete Bibliothek ersetzt, entfernt es den alten Dateiverzeichniseintrag und schreibt eine neue Datei. Ein Prozess, der die alte Datei bereits eingebunden hat, hält den alten Inode aktiv und führt weiterhin den alten Code aus. openssl-libs ist der wichtigste Fall: Eine Fehlerbehebung in libcrypto erreicht Ihren Webserver erst, nachdem dieser neu gestartet wurde.

sudo needs-restarting -s

Damit werden die systemd-Dienste aufgelistet, deren eigene Dateien oder die Dateien ihrer Abhängigkeiten aktualisiert wurden, nachdem der Dienst gestartet wurde. Verwenden Sie sudo. Ohne root kann das Tool nur /proc-Einträge für Ihre eigenen Prozesse lesen. Dadurch werden zu wenige Einträge angezeigt, und die kurze Liste wirkt fälschlicherweise beruhigend.

sudo needs-restarting
sudo needs-restarting --exclude-services

Der erste Befehl gibt die PID und die Befehlszeile jedes betroffenen Prozesses aus. Der zweite entfernt die Prozesse, die bereits von einem systemd-Dienst abgedeckt sind. Übrig bleiben Login-Shells, tmux-Sitzungen, Cron-Jobs und alles, was Sie manuell gestartet haben. Diese Prozesse werden niemals automatisch neu gestartet.

Wenn ein Dienst aus der Liste auch zu einem Paket der Reboot-Stufe gehört, gibt das Tool darüber Warning: The following services should not be restarted but require a reboot: aus. Nehmen Sie das wörtlich und führen Sie stattdessen einen Reboot durch.

Starten Sie die übrigen Dienste nacheinander neu. Prüfen Sie jeden Dienst, bevor Sie mit dem nächsten fortfahren.

sudo systemctl restart nginx
systemctl status nginx

Leiten Sie die Liste nicht an systemctl restart weiter. Ihre eigene SSH-Sitzung ist der Grund dafür. Auf der RHEL-Familie wird sshd.service zusammen mit KillMode=process ausgeliefert. Beim Neustart signalisiert es dem lauschenden Daemon und lässt die Prozesse für die einzelnen Verbindungen unverändert. Dadurch bleibt eine offene Sitzung bestehen. Prüfen Sie das auf Ihrem eigenen System mit systemctl cat sshd | grep KillMode. Lassen Sie beim ersten Mal trotzdem eine zweite Sitzung geöffnet.

Sie können dieselben Prozesse auch ohne DNF finden. Das ist hilfreich, wenn Sie die betroffenen Dateipfade anzeigen möchten:

sudo dnf install -y lsof
sudo lsof -n +c 0 2>/dev/null | grep -w DEL

DEL kennzeichnet eine eingebundene Datei, die von der Festplatte gelöscht wurde. Lesen Sie die Pfade, bevor Sie Maßnahmen ergreifen. Gelöschte temporäre Dateien und speicherbasierte Dateien werden hier ebenfalls angezeigt. Sie sind kein Grund, etwas neu zu starten.

Tier 3: alle übrigen Pakete

Die meisten Updates fallen in diese Kategorie und erfordern keine weiteren Maßnahmen. Bei einem Paket, dessen Dateien erst beim Start eines Befehls gelesen werden, beispielsweise curl, tar, vim oder dnf selbst, ist das Update abgeschlossen, sobald RPM beendet wurde, weil der nächste Aufruf die neue Binärdatei einliest. Konfigurationsdateien, Skripte, Dokumentation und Datenpakete verhalten sich genauso. needs-restarting wird keines dieser Pakete erwähnen. Dieses Ausbleiben einer Meldung ist das korrekte Ergebnis und keine übersehene Erkennung.

Der einzige wichtige Punkt in dieser Kategorie ist die Laufzeit. Ein Prozess, der vor dem Update gestartet wurde, verwendet weiterhin seine alte ausführbare Datei, bis er beendet wird. Das gilt auch bei einem noch so unkritischen Paket. Genau dafür dient sudo needs-restarting --exclude-services.

Warum ein Rechner mit dnf-automatic wochenlang nicht angewendete Korrekturen enthalten kann

Hier zeigt sich, dass die drei Stufen keine Nebensache sind. Automatische Updates mit dnf-automatic installieren Pakete nach einem Zeitplan. Die Standardeinstellung reboot in /etc/dnf/automatic.conf lautet never. Mit apply_updates = yes und reboot = never kann ein Rechner über sechs Wochen sechs Kernel-Updates und eine glibc-Korrektur installieren und trotzdem noch den Kernel und die C-Bibliothek ausführen, mit denen er in Woche null gestartet wurde. Das Update-Log sieht einwandfrei aus. Das laufende System enthält keines dieser Updates.

Die Lösung besteht aus drei Zeilen in /etc/dnf/automatic.conf:

[commands]
upgrade_type = security
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

reboot akzeptiert never, when-changed und when-needed. never ist die Standardeinstellung und überlässt jede Entscheidung Ihnen. when-changed führt nach jeder Transaktion, die ein Paket geändert hat, einen Reboot durch. Das ist grob, aber vorhersehbar. when-needed fragt DNF, ob die gerade angewendete Transaktion einen Reboot erfordert. Dadurch läuft eine Update-Nacht mit Änderungen ausschließlich im Userspace ohne Reboot durch. reboot_command führt den Reboot tatsächlich aus. Standardmäßig erhalten angemeldete Benutzer fünf Minuten Vorwarnzeit. Setzen Sie random_sleep und den Zeitplan des Timers so, dass der Reboot in ein Zeitfenster fällt, in dem Sie beobachten können, wie der Rechner wieder hochfährt.

Prüfen Sie mit systemctl list-timers 'dnf-*', welche Unit Sie aktiviert haben. dnf-automatic wird mit mehreren Varianten ausgeliefert, die sich nicht alle gleich verhalten. Die Konfigurationsdatei allein zeigt daher nicht, was tatsächlich ausgeführt wird.

Fragen Sie den Rechner nach einem geplanten Lauf direkt ab, statt nur das Log zu prüfen:

needs-restarting -r; echo "exit: $?"
uname -r
rpm -q --last kernel | head -1

Wenn Sie den Reboot nicht planen können, ist Live-Kernel-Patching auf einem VPS eine weitere Möglichkeit. Dabei werden bestimmte Kernel-Korrekturen ohne Reboot auf den laufenden Kernel angewendet. Das deckt nur einen Teil der Kernel-Probleme ab und hat keine Wirkung auf glibc oder Ihre Dienste. Betrachten Sie es daher als Möglichkeit, Reboots zeitlich weiter auseinanderzuziehen, nicht als Ersatz dafür. Wenn Sie einen Reboot durchführen, tun Sie dies bewusst und bleiben Sie angemeldet, bis der Rechner wieder antwortet. Ein Kernel-Update ist der häufigste Grund dafür, dass ein Rechner nicht zurückkommt. Lesen Sie was zu tun ist, wenn ein VPS nach einem Kernel-Update nicht bootet, bevor Sie einen Rechner ohne Konsolenzugriff rebooten. Nehmen Sie die Reboot-Prüfung außerdem in eine regelmäßige Checkliste für die Serverwartung auf, damit Sie nicht erst nach einem Vorfall daran denken.

Dieselbe Aufgabe unter Ubuntu und Debian

Für eine gemischte Umgebung benötigen Sie die entsprechenden Gegenstücke. Unter Ubuntu und Debian ist das Reboot-Flag eine Datei und kein Befehl: Paketskripte erstellen /run/reboot-required, und /run/reboot-required.pkgs listet auf, welche Pakete diese Datei angefordert haben. Daher ist [ -f /run/reboot-required ] das direkte Gegenstück zu needs-restarting -r. In älterer Dokumentation steht /var/run/reboot-required. Dabei handelt es sich um dieselbe Datei, weil /var/run ein symbolischer Link auf /run ist. Die zuständige Service-Komponente ist needrestart. Sie ist in aktuellen Ubuntu-Server-Releases standardmäßig installiert, läuft während apt upgrade und kann mit sudo needrestart -r l separat ausgeführt werden, um aufzulisten, welche Dienste neu gestartet werden müssen, ohne Änderungen vorzunehmen. Die Lücke bei automatischen Updates ist dort identisch, ebenso die Lösung: unattended-upgrades unter Ubuntu setzt Unattended-Upgrade::Automatic-Reboot "true"; und Unattended-Upgrade::Automatic-Reboot-Time "02:00"; in /etc/apt/apt.conf.d/50unattended-upgrades.

Fehlerbilder und ihre Bedeutung

• needs-restarting: command not found bedeutet, dass dnf-utils nicht installiert ist. Installieren Sie es oder rufen Sie stattdessen dnf needs-restarting auf. Dieser Befehl funktioniert, sobald dnf-plugins-core vorhanden ist.
• Ein Skript, das bei der Prüfung auf einen Neustart ohne Fehlermeldung beendet wird, erhält unter set -e den Exit-Code 1. Dieser Code bedeutet „Neustart erforderlich“. Verzweigen Sie anhand dieses Codes, statt das Skript dadurch zu beenden.
• Wenn needs-restarting -s direkt nach einer Bibliotheksaktualisierung nichts ausgibt, wurde der Befehl normalerweise ohne sudo ausgeführt. Ohne root werden nur die Prozesse des eigenen Benutzers angezeigt.
• Wenn needs-restarting -r keinen Neustart meldet, während uname -r eine alte Version anzeigt, wurde ein älterer Kernel gestartet. Die Prüfung vergleicht den Installationszeitpunkt mit dem Bootzeitpunkt. Beide Zeitpunkte liegen inzwischen vor dem aktuellen Zeitpunkt. Prüfen Sie grubby --default-kernel.
• Wenn ein Dienst beim nächsten Durchlauf wenige Minuten nach dem Neustart wieder angezeigt wird, wird er normalerweise von einer anderen Komponente erneut gestartet oder die Unit konnte nicht wieder starten. Lesen Sie zunächst systemctl status für diese Unit, bevor Sie sie ein zweites Mal neu starten.

FAQ

Startet dnf update Dienste unter Rocky Linux neu?

In der Regel nein. Die Transaktion schreibt Dateien und endet. Einige Pakete enthalten ein RPM-Scriptlet, das ihren eigenen Dienst beim Upgrade neu startet. Das Verhalten hängt daher vom jeweiligen Paket ab und ist keine systemweite Garantie. Behandeln Sie sudo needs-restarting -s als maßgebliche Quelle: Dort werden die Dienste aufgeführt, deren Dateien oder die Dateien ihrer Abhängigkeiten nach dem Start des Dienstes geändert wurden, unabhängig davon, was die Scriptlets ausgeführt haben.

Warum meldet needs-restarting -r, dass kein Reboot erforderlich ist, obwohl ein neuerer Kernel installiert wurde?

Weil der Befehl die RPM-Installationszeit einer kurzen Liste zentraler Pakete mit der Bootzeit des Systems vergleicht. Die Version des laufenden Kernels wird niemals mit der neuesten installierten Version verglichen. Wenn Sie einen Kernel installiert, das System neu gestartet und anschließend wieder einen älteren Kernel verwendet haben, weil der Standard des Bootloaders auf diesen Kernel verweist, liegt die Installationszeit vor der Bootzeit. Die Prüfung meldet dann keinen Reboot-Bedarf. Führen Sie uname -r, rpm -q --last kernel und sudo grubby --default-kernel aus, um den tatsächlichen Zustand zu prüfen.

Welche Pakete lösen den Reboot-Hinweis unter Rocky und Alma aus?

Eine fest codierte Liste im Plugin. In aktuellen Versionen enthält sie kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Sie können die Liste erweitern: Legen Sie eine Datei .conf in /etc/dnf/plugins/needs-restarting.d/ ab. Sie muss Paketnamen enthalten, jeweils einen pro Zeile. Diese Namen werden ebenfalls bei der Reboot-Prüfung berücksichtigt.

Kann dnf-automatic den Server selbstständig neu starten?

Ja. Setzen Sie reboot = when-needed im Abschnitt [commands] von /etc/dnf/automatic.conf. Dann wird der Server nur neu gestartet, wenn die angewendete Transaktion einen Reboot erfordert. when-changed führt nach jeder Paketänderung einen Reboot aus. never ist die Standardeinstellung. reboot_command steuert das Verhalten. Der Standardwert warnt angemeldete Benutzer fünf Minuten vorher. Aktivieren Sie diese Funktion nur auf einem System, dessen Bootvorgang Sie wiederherstellen können. Ein unbeaufsichtigter Reboot einer VPS ohne Konsolenzugriff kann andernfalls zu einem schwerwiegenden Ausfall führen.

Erkennt needs-restarting Prozesse in Containern?

Nicht zuverlässig. Der Befehl gleicht laufende Prozesse mit der RPM-Datenbank des Hosts ab. Pakete in einem Container-Image sind nicht in dieser Datenbank enthalten. Eine veraltete Bibliothek, die in ein Image integriert wurde, wird daher nicht erkannt. Erstellen Sie das Image neu und stellen Sie es erneut bereit. Die Host-Seite bleibt dennoch relevant: Die Container-Runtime und der gemeinsam verwendete Kernel sind Pakete des Hosts und werden erkannt.