Rocky und Alma: Welche Updates brauchen einen Reboot?

Welche Updates benötigen unter Rocky Linux und AlmaLinux einen Reboot?

Unter Rocky Linux und AlmaLinux schreibt dnf update neue Dateien auf die Festplatte und beendet den Vorgang. 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 so lange vorhält, bis der letzte Prozess, der sie verwendet, beendet wird. Daher kann das System keine verfügbaren Updates mehr melden, obwohl es weiterhin den Code ausführt, den diese Updates ersetzt haben. Das Verhalten ist bei beiden Distributionen identisch, weil beide aus denselben Red-Hat-Quellen erstellt werden. Die Wahl zwischen Rocky und Alma hängt von Kompatibilitätszusagen und CPU-Unterstützung ab, nicht von etwas, das Sie in diesem Zusammenhang sehen werden. Die folgenden Befehle sind ebenfalls dieselben, die ein CentOS-System verwendet hat. Das ist kein Zufall: Beide Projekte wurden nach der Stream-Ankündigung von 2020 als CentOS-Ersatz entwickelt.

Welche Updates einen Reboot benötigen und bei welchen ein Neustart des Dienstes ausreicht, muss das System selbst beantworten. Der dafür zuständige Befehl ist needs-restarting. Updates werden in drei Kategorien eingeteilt. Der Kernel und eine kurze Liste zentraler Pakete benötigen einen vollständigen Reboot. Bei gewöhnlichen Bibliotheksupdates müssen Sie die Dienste neu starten, die diese Bibliotheken verwenden. Alle übrigen Updates sind bereits angewendet, sobald RPM seine Arbeit 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 kleiner Wrapper aus yum-utils, der auch unter dem Namen dnf-utils verfügbar ist.

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

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

needs-restarting -r
dnf needs-restarting -r

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

Die Versionen Rocky Linux 10 und AlmaLinux 10 verwenden weiterhin DNF 4. Seit 2026-10-09 enthalten beide BaseOS-Repositories dnf 4.20.0 zusammen mit dnf-plugins-core 4.7.0 und yum-utils, jedoch kein dnf5-Paket. needs-restarting ist dort daher dasselbe dnf-plugins-core-Plugin, das auf dieser Seite beschrieben wird, und alle folgenden Angaben gelten unverändert. Das gilt auch für -r. Es erzeugt den Neustarthinweis und den zugehörigen Exit-Code. Verwenden Sie es daher weiterhin in Ihren Skripten.

Tier 1: Updates, die einen Reboot erfordern

Führen Sie zuerst die Reboot-Prüfung aus. Sie liest nur die RPM-Datenbank und die System-Bootzeit. Daher ist sie schnell und erfordert keinen root-Zugriff.

needs-restarting -r

Wenn sich seit dem Boot nichts Wichtiges geändert hat, werden zwei Zeilen ausgegeben:

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

Wenn sich etwas geändert hat, wird Core libraries or services have been updated since boot-up: ausgegeben, 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 ein Reboot erforderlich ist. Gegen diesen Wert richten Sie Ihre Skripte.

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

Der Exit-Code 1 ist hier eine normale Antwort und kein Fehler. Unter set -e beendet ein ungeschütztes needs-restarting -r Ihr Skript an dieser Stelle. Deshalb wird es im obigen Beispiel in if eingeschlossen.

Die Pakete, die einen Reboot 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. Die Änderung wird daher erst beim nächsten Boot wirksam. Jeder Prozess auf dem System ist mit glibc verknüpft. Das bedeutet, dass „die betroffenen Dienste neu starten“ auch einen Neustart von PID 1 erfordern würde. Ein Reboot ist dafür die sichere Variante. dbus und dbus-broker übertragen jede Clientverbindung auf dem System. Wenn Sie den Bus auf einem laufenden System stoppen, werden die verbundenen Clients unterbrochen. linux-firmware und microcode_ctl werden beim Boot geladen. Bei einem VPS ändert der Microcode normalerweise nichts Beobachtbares, 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, wobei pro Zeile ein Name steht. 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 bedeutet: „Wenn sich die TLS-Bibliothek ändert, führe ich lieber einen Reboot durch, statt jeden Dienst zu ermitteln, der sie eingebunden hat.“

Woraus der Hinweis auf einen Neustart tatsächlich abgeleitet wird

needs-restarting -r vergleicht die laufende Kernelversion nicht mit dem neuesten installierten Kernel. Das Programm vergleicht Zeitstempel. Für jedes Paket in dieser Kernliste liest es die RPM-Installationszeit und vergleicht sie mit dem Zeitpunkt, zu dem das System gestartet wurde. Wenn ein Kernpaket nach dem letzten Boot installiert wurde, lautet das Ergebnis „Neustart erforderlich“. Die Bootzeit wird über systemd's UnitsLoadStartTimestamp via D-Bus ermittelt, sofern dies verfügbar ist. 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 anschließend wegen einer festgelegten Boot-Standardeinstellung wieder mit einem älteren Kernel starten, liegt die Installationszeit nun vor der Bootzeit, und needs-restarting -r meldet nichts mehr. Das Programm beantwortet seine eigene Frage korrekt. Es 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 den laufenden Kernel an. Die erste Zeile von rpm -q --last kernel enthält den zuletzt installierten Kernel. grubby --default-kernel zeigt an, welchen Kernel der Bootloader beim nächsten Start auswählt. Wenn diese drei Angaben voneinander abweichen, korrigieren Sie die Boot-Standardeinstellung, bevor Sie einen Rechner neu starten, den Sie nicht über eine Konsole erreichen können.

Tier 2: Updates, die einen Neustart des Dienstes erfordern

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

sudo needs-restarting -s

Dieser Befehl listet die systemd-Dienste auf, deren eigene Dateien oder die Dateien ihrer Abhängigkeiten nach dem Start des Dienstes aktualisiert wurden. Verwenden Sie sudo. Ohne root kann das Tool nur /proc-Einträge für Ihre eigenen Prozesse lesen. Daher werden stillschweigend zu wenige Einträge erfasst, 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 nicht automatisch neu gestartet.

Wenn ein Dienst auf der Liste außerdem 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 starten Sie den Server stattdessen neu.

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 mit KillMode=process ausgeliefert. Dadurch signalisiert der Neustart dem auf Verbindungen wartenden Daemon den Neustart und lässt die Prozesse für bestehende Verbindungen unverändert. Eine offene Sitzung bleibt erhalten. Prüfen Sie dies auf Ihrem eigenen System mit systemctl cat sshd | grep KillMode, und lassen Sie beim ersten Versuch unabhängig davon eine zweite Sitzung geöffnet.

Sie können dieselben Prozesse auch ohne DNF finden. Das ist nützlich, wenn Sie die betroffenen Dateipfade sehen möchten:

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

DEL kennzeichnet eine gemappte Datei, die von der Festplatte gelöscht wurde. Lesen Sie die Pfade, bevor Sie handeln. Gelöschte temporäre Dateien und speicherbasierte Dateien werden hier ebenfalls angezeigt. Sie sind kein Grund, einen Dienst neu zu starten.

Tier 3: alle übrigen Fälle

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

Der einzige Aspekt dieser Kategorie ist die Laufzeit. Ein vor dem Update gestarteter Prozess verwendet weiterhin seine alte ausführbare Datei, bis er beendet wird, unabhängig davon, wie unkritisch das Paket war. Genau dafür ist sudo needs-restarting --exclude-services vorgesehen.

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

Hier zeigt sich, dass die drei Ebenen 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 System innerhalb von sechs Wochen sechs Kernel-Updates und eine glibc-Korrektur installieren und trotzdem weiterhin den Kernel und die C-Bibliothek verwenden, mit denen es in Woche null gestartet wurde. Das Update-Log sieht vollständig korrekt aus. Das laufende System enthält jedoch keine dieser Aktualisierungen.

Die Korrektur 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 startet das System nach jeder Transaktion neu, die ein Paket geändert hat. Das ist undifferenziert, aber vorhersehbar. when-needed fragt DNF, ob die gerade angewendete Transaktion einen Neustart erfordert. Eine Nacht mit reinen Userspace-Aktualisierungen kommt dadurch ohne Neustart aus. reboot_command führt den Neustart tatsächlich aus. Standardmäßig erhalten angemeldete Benutzer fünf Minuten Vorwarnung. Legen Sie random_sleep und den Zeitplan des Timers so fest, dass der Neustart in ein Zeitfenster fällt, in dem Sie beobachten können, wie das System wieder startet.

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

Fragen Sie das System 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 Neustart nicht einplanen können, ist Live-Kernel-Patching auf einem VPS eine weitere Möglichkeit. Dabei werden bestimmte Kernel-Korrekturen ohne Neustart auf den laufenden Kernel angewendet. Das deckt nur einen Teil der Kernel-Probleme ab und behebt weder glibc noch Probleme mit Ihren Diensten. Verwenden Sie es daher, um Neustarts zeitlich auseinanderzuziehen, nicht um vollständig auf sie zu verzichten. Wenn Sie neu starten, tun Sie dies bewusst und bleiben Sie angemeldet, bis das System wieder antwortet. Ein Kernel-Update ist der häufigste Grund dafür, dass ein System nicht zurückkommt. Lesen Sie was zu tun ist, wenn ein VPS nach einem Kernel-Update nicht startet, bevor Sie ein System ohne Konsolenzugriff neu starten. Nehmen Sie die Prüfung des Neustarts außerdem in eine regelmäßige Wartungscheckliste für Server auf, damit Sie nicht erst nach einem Vorfall daran denken.

Die gleiche Aufgabe unter Ubuntu und Debian

In einer gemischten Systemlandschaft benötigen Sie die entsprechenden Befehle und Dateien. Unter Ubuntu und Debian ist das Reboot-Flag eine Datei, kein Befehl: Paketskripte erstellen /run/reboot-required, und /run/reboot-required.pkgs listet auf, welche Pakete diese Datei angefordert haben. Damit 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 Symlink auf /run ist. Für die Dienste ist needrestart zuständig. Es wird in aktuellen Ubuntu-Server-Versionen standardmäßig installiert. Der Dienst läuft während apt upgrade und kann mit sudo needrestart -r l auch separat ausgeführt werden. Dabei wird aufgelistet, welche Dienste neu gestartet werden müssen, ohne Änderungen vorzunehmen. Die Lücke bei automatischen Updates ist dort identisch. Das gilt auch für die Lösung: unattended-upgrades unter Ubuntu verwendet 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 yum-utils nicht installiert ist. Installieren Sie es, oder verwenden Sie stattdessen dnf needs-restarting. 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“. Prüfen Sie diesen Code daher in einer Verzweigung, statt das Skript dadurch beenden zu lassen.
• Wenn needs-restarting -s direkt nach einer Bibliotheksaktualisierung nichts ausgibt, wurde der Befehl in der Regel ohne sudo ausgeführt. Ohne root sieht der Befehl nur Ihre eigenen Prozesse.
• 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 bereits zurück. Prüfen Sie grubby --default-kernel.
• Ein Dienst, der beim nächsten Durchlauf wenige Minuten nach dem Neustart wieder erscheint, wird in der Regel von einer anderen Komponente neu gestartet, oder die Unit konnte nicht erneut gestartet werden. Lesen Sie 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 nicht. 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 nicht systemweit garantiert. Betrachten Sie sudo needs-restarting -s als maßgeblich: Dort sind die Dienste aufgeführt, deren Dateien oder die Dateien ihrer Abhängigkeiten geändert wurden, nachdem der Dienst gestartet wurde, 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 nie mit der neuesten installierten Version verglichen. Wenn Sie einen Kernel installiert, das System neu gestartet haben und anschließend wegen eines entsprechenden Bootloader-Standardeintrags wieder mit einem älteren Kernel gestartet sind, 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. Die Datei muss Paketnamen enthalten, 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 ein Reboot nur durchgeführt, wenn die angewendete Transaktion ihn erfordert. when-changed startet das System nach jeder Paketänderung neu. never ist die Standardeinstellung. reboot_command steuert das Verfahren. Die Standardeinstellung warnt angemeldete Benutzer fünf Minuten vorher. Aktivieren Sie diese Funktion nur auf einem System, dessen Boot-Vorgang Sie wiederherstellen können. Ein unbeaufsichtigter Reboot auf einem VPS ohne Konsolenzugriff kann sonst zu einem schwerwiegenden Ausfall führen.

Erkennt needs-restarting Prozesse innerhalb von Containern?

Nicht zuverlässig. Der Befehl gleicht laufende Prozesse mit der RPM-Datenbank des Hosts ab. Pakete innerhalb eines Container-Images 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 rollen Sie es erneut aus. Die Host-Seite bleibt trotzdem relevant: Die Container-Runtime und der gemeinsam verwendete Kernel sind Pakete des Hosts und werden erkannt.