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-Unterkommando aufruft:

needs-restarting -r
dnf needs-restarting -r

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

Die Rocky-Linux-10- und AlmaLinux-10-Reihe verwendet weiterhin DNF 4. Stand 2026-10-12 enthalten die beiden BaseOS-Repositorys dnf 4.20.0 zusammen mit dnf-plugins-core 4.7.0 und yum-utils, aber kein Paket dnf5. needs-restarting ist dort daher dasselbe dnf-plugins-core-Plugin, das auf dieser Seite beschrieben wird, und alle folgenden Angaben gelten auch dort. Dazu gehört -r. Dieses erzeugt den Neustarthinweis und seinen Exit-Code. Verwenden Sie es daher weiterhin in Ihren Skripten. Rocky und Alma 9 enthalten den älteren dnf-plugins-core-Build 4.3.0. Die wenigen Stellen, an denen sich die beiden Builds unterschiedlich verhalten, sind unten gekennzeichnet.

Stufe 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. Daher ist sie schnell und erfordert keine root-Berechtigungen.

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, anschließend die gefundenen Paketnamen und danach:

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. Auf diesen Teil stützen 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 nicht abgesichertes needs-restarting -r Ihr Skript an dieser Stelle. Deshalb wird es im obigen Beispiel in if eingeschlossen.

Die Pakete, die die Reboot-Antwort auslösen, stehen als kurze, fest codierte Liste im Plugin. In den Builds, die Rocky Linux 10 und AlmaLinux 10 bereitstellen, enthält sie kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Der Build für Rocky und Alma 9 enthält dieselbe Liste ohne kernel-core. Das ist aus dem im nächsten Abschnitt erklärten Grund relevant. Prüfen Sie Ihre Liste, statt diese Werte vorauszusetzen.

Jeder Eintrag steht aus einem klaren 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. Daher wird die Änderung erst nach dem nächsten Boot wirksam. Fast jeder Userspace-Prozess auf dem System ist mit glibc verknüpft, einschließlich PID 1. Das bedeutet, dass „die betroffenen Dienste neu starten“ auch den Neustart von PID 1 erfordern würde. Ein Reboot ist dafür die sichere Variante. dbus und dbus-broker übertragen alle Client-Verbindungen auf dem System. Wenn Sie den Bus auf einem laufenden System stoppen, werden die Clients unterbrochen, 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 in die Reboot-Liste aufgenommen.

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

Das ist eine Richtlinienentscheidung und keine Fehlerbehebung. Sie besagt: „Wenn sich die TLS-Bibliothek ändert, möchte ich lieber rebooten, als jeden Dienst zu ermitteln, der sie geladen hat.“

Woraus der Neustart-Hinweis tatsächlich abgeleitet wird

needs-restarting -r vergleicht nicht die Version des laufenden Kernels mit dem neuesten installierten Kernel. Stattdessen vergleicht es 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. Wurde ein Kernpaket nach dem letzten Start installiert, lautet die Antwort „Neustart erforderlich“. Die Startzeit stammt, sofern verfügbar, über D-Bus aus systemd und dessen UnitsLoadStartTimestamp. 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. 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, was gerade läuft. 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 nicht übereinstimmen, korrigieren Sie den Boot-Standard, bevor Sie eine Maschine neu starten, auf die Sie nicht über eine Konsole zugreifen können.

Rocky und Alma 9 haben eine weitere Lücke. Da ihr Plugin-Build kernel, aber nicht kernel-core überwacht, installiert eine Transaktion, die kernel-core ohne das Paket kernel aktualisiert, zwar einen neuen Kernel, dieser läuft aber noch nicht. Gleichzeitig meldet needs-restarting -r, dass kein Neustart erforderlich ist. Red Hat dokumentiert dieses Verhalten für Enterprise Linux 9. Ein reguläres dnf update auf einer Maschine mit installiertem Paket kernel aktualisiert auch dieses Paket, sodass der Hinweis weiterhin ausgelöst wird. Führen Sie rpm -q kernel aus, um dies zu prüfen. Wenn gemeldet wird, dass das Paket nicht installiert ist, erkennt der Neustart-Hinweis Kernel-Updates auf dieser Maschine nicht. Vergleichen Sie stattdessen uname -r mit rpm -q --last kernel-core.

Tier 2: Updates, die einen Dienstneustart erfordern

Wenn RPM eine gemeinsam verwendete Bibliothek ersetzt, entfernt es die Verknüpfung zur alten Datei 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

Dies listet die systemd-Dienste auf, 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. Daher werden stillschweigend zu wenige Einträge erfasst, und die kurze Liste wirkt fälschlicherweise positiv.

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 werden. Übrig bleiben Login-Shells, tmux-Sitzungen, Cron-Jobs und alles, was Sie manuell gestartet haben. Diese Prozesse werden nicht automatisch neu gestartet. --exclude-services ist nur im Rocky- und Alma-10-Build vorhanden. Unter 9 gibt es diese Option nicht. Lesen Sie dort die vollständige sudo needs-restarting-Liste und sortieren Sie die Prozesse aus, die zu Diensten aus der Ausgabe von -s gehören.

Starten Sie keinen Dienst aus der Liste neu, der zu einem Paket der Reboot-Stufe gehört, beispielsweise dbus-broker.service. Führen Sie stattdessen einen Reboot durch. Stand 2026-10-12 geben die Builds, die Rocky Linux und AlmaLinux ausliefern, einen solchen Dienst weiterhin wie jeden anderen aus. Das CentOS Stream 10-Paket erhielt im Juli 2026 eine Änderung, durch die diese Dienste aus der Liste entfernt werden und stattdessen Warning: The following services should not be restarted but require a reboot: auf stderr ausgegeben wird. Sobald diese Änderung in Ihrer Release enthalten ist, sollten Sie die Warnung wörtlich nehmen.

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. In der RHEL-Familie wird sshd.service mit KillMode=process ausgeliefert. Dadurch signalisiert der Dienst dem lauschenden Daemon, während die Prozesse pro Verbindung weiterlaufen, und eine offene Sitzung bleibt bestehen. Prüfen Sie dies auf Ihrem eigenen System mit systemctl cat sshd | grep KillMode. Lassen Sie beim ersten Mal trotzdem immer eine zweite Sitzung geöffnet.

Sie können dieselben Prozesse auch ohne DNF finden. Das ist nützlich, 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: alles andere

Die meisten Updates gehören in diese Kategorie und erfordern nichts weiter. Ein Paket, dessen Dateien erst beim Start eines Befehls gelesen werden, beispielsweise curl, tar, vim oder dnf selbst, ist abgeschlossen, sobald RPM beendet ist, weil der nächste Aufruf die neue Binärdatei verwendet. Konfigurationsdateien, Skripte, Dokumentation und Datenpakete verhalten sich genauso. needs-restarting wird keines davon melden. 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 seine alte ausführbare Datei weiter, bis er beendet wird, unabhängig davon, wie unbedeutend das Paket war. Genau dafür ist sudo needs-restarting --exclude-services vorgesehen. Alternativ verwenden Sie unter 9 einfach sudo needs-restarting.

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 das Paket, oder verwenden Sie stattdessen dnf needs-restarting. Dieser Befehl funktioniert, sobald dnf-plugins-core vorhanden ist.
• Ein Skript, das bei der Reboot-Prüfung ohne Fehlermeldung beendet wird, erhält unter set -e den Exit-Code 1. Dieser Code bedeutet „Reboot erforderlich“. Prüfen Sie den Rückgabewert und verzweigen Sie entsprechend, statt das Skript beenden zu lassen.
• Wenn needs-restarting -s direkt nach einer Bibliotheksaktualisierung nichts ausgibt, wurde der Befehl normalerweise ohne sudo ausgeführt. Ohne root sieht der Befehl nur Ihre eigenen Prozesse.
• Wenn needs-restarting -r keinen Reboot meldet, während uname -r eine ältere Version als der zuletzt installierte Kernel anzeigt, wurde ein älterer Kernel gestartet. Die Prüfung vergleicht den Installationszeitpunkt mit dem Bootzeitpunkt. Beide Zeitpunkte liegen dann bereits zurück. Prüfen Sie grubby --default-kernel. Unter Rocky oder Alma 9 gibt es eine zweite Ursache: Das Update hat kernel-core ohne das Paket kernel geändert. Der Build für 9 überwacht diese Änderung nicht. Daher steht weiterhin ein Reboot aus.
• Wenn needs-restarting --exclude-services mit einem Fehler wegen eines unbekannten Arguments fehlschlägt, verwenden Sie den Build für 9. Dieser unterstützt diese Option nicht. Verwenden Sie stattdessen einfach sudo needs-restarting.
• Wenn ein Dienst beim nächsten Lauf wenige Minuten nach dem Neustart wieder aktiv ist, wird er normalerweise von einem anderen Prozess erneut gestartet, oder die Unit konnte nicht ordnungsgemäß starten. 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 jedoch ein RPM-Skriptfragment, das den 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 sind die Dienste aufgeführt, deren Dateien oder die Dateien ihrer Abhängigkeiten seit dem Start des Dienstes geändert wurden, unabhängig davon, was die Skriptfragmente 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 installieren, einen Reboot ausführen und anschließend wegen eines entsprechenden Bootloader-Standardeintrags mit einem älteren Kernel starten, liegt die Installationszeit vor der Bootzeit. Die Prüfung meldet dann keinen Handlungsbedarf. Unter Rocky und Alma 9 wird außerdem ein kernel-core-Update übersehen, das ohne das Paket kernel ausgeführt wurde, weil kernel-core nicht in der Paketliste des 9-Builds enthalten ist. 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 im Plugin hinterlegte Liste. Unter Rocky und Alma 10 enthält sie kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Unter 9 ist es dieselbe Liste ohne kernel-core. Sie können die Liste erweitern: Legen Sie eine Datei .conf unter /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] der Datei /etc/dnf/automatic.conf. Dann wird der Server nur neu gestartet, wenn die ausgeführte Transaktion einen Reboot erfordert. when-changed führt nach jeder Paketänderung einen Reboot aus. never ist der Standardwert. reboot_command steuert das Vorgehen. Der Standardwert warnt angemeldete Benutzer fünf Minuten vorher. Aktivieren Sie diese Option nur auf einem System, dessen Bootvorgang Sie wiederherstellen können. Ein unbeaufsichtigter Reboot auf einem VPS ohne Konsolenzugriff führt sonst zu einem schwerwiegenden Ausfall.

Erkennt needs-restarting Prozesse innerhalb von Containern?

Nicht zuverlässig. Der Befehl vergleicht laufende Prozesse mit der RPM-Datenbank des Hosts. Pakete innerhalb eines Container-Images sind nicht in dieser Datenbank enthalten. Eine veraltete, in ein Image integrierte Bibliothek wird daher nicht angezeigt. Erstellen Sie das Image neu und stellen Sie es erneut bereit. Die Host-Seite bleibt trotzdem relevant: Die Container-Laufzeitumgebung und der gemeinsam genutzte Kernel sind Host-Pakete und werden erkannt.