Prüfen, ob ein Linux-Host nach Updates einen Neustart oder einen Dienstneustart benötigt

Ziel

Nach dem Einspielen von Paketupdates ohne Raten feststellen, ob der Host einen vollständigen Neustart benötigt (Kernel oder zentrale Bibliothek geändert) oder ob nur bestimmte Dienste neu gestartet werden müssen (eine Shared Library geändert, der Kernel aber nicht).

Voraussetzungen

Root- oder sudo-Zugriff; die Updates sind bereits über den Paketmanager der Distribution eingespielt.

Schritte

1. Unter Debian und Ubuntu die Markerdatei prüfen, die das Update-Tooling selbst schreibt: test -f /var/run/reboot-required && echo "reboot required". Die Datei wird von Paket-Hooks geschrieben, nicht von apt selbst – unter Ubuntu von update-notifier-common, unter Debian vom Kernel-Hook von unattended-upgrades. Auf einem Debian-Host ohne diese Pakete beweist ihr Fehlen daher nichts. Ist needrestart installiert, kann es zusätzlich nach einem Upgrade betroffene Dienste neu starten; konfiguriert wird es in /etc/needrestart/needrestart.conf und in Drop-ins unter /etc/needrestart/conf.d/.
2. Weiterhin unter Debian/Ubuntu oder als Gegenprobe überall, wo needrestart installiert ist, das Tool direkt ausführen, um Dienste aufzulisten (oder im passenden Modus neu zu starten), die nun veraltete Dateien verwenden: needrestart -b liefert einen nicht interaktiven Bericht im Batch-Format, der sich für Skripte eignet.
3. Unter RHEL, Fedora und anderen DNF/YUM-basierten Systemen die Funktion needs-restarting aus dnf-plugins-core (oder yum-utils) verwenden: dnf needs-restarting -r (bzw. yum needs-restarting -r) beendet sich mit Exit-Code 1, wenn ein Neustart empfohlen wird, und mit 0, wenn nicht. Damit lässt es sich direkt in einer Exit-Code-Prüfung in Skripten einsetzen. Ohne -r werden stattdessen die einzelnen Prozesse aufgelistet, die gelöschte oder aktualisierte Dateien verwenden. Fedora 41 und neuer enthalten DNF5, dessen needs-restarting andere Optionen hat; dort dnf needs-restarting --help konsultieren, statt die Optionen von DNF4 vorauszusetzen.
4. Auf jeder systemd-basierten Distribution, unabhängig von der Familie, den laufenden Kernel mit dem neuesten installierten vergleichen: uname -r liefert das Release des laufenden Kernels; dieses mit dem neuesten Eintrag aus rpm -q kernel --last (RHEL-Familie) bzw. dpkg -l 'linux-image-*' / ls /boot/vmlinuz-* (Debian-Familie) vergleichen. Weichen die Versionen voneinander ab, ist ein Kernel-Update installiert, das noch nicht läuft.
5. Die Massnahme anhand der gesamten Befunde festlegen: Eine Abweichung bei Kernel oder glibc erfordert einen Neustart; nennt die Liste von needs-restarting/needrestart nur einzelne Dienste, genügt es, genau diese neu zu starten (systemctl restart <unit> für jeden einzelnen).

Erwartetes Ergebnis

Eine klare Ja/Nein-Aussage zum Neustart, belegt entweder durch die Markerdatei oder durch einen Vergleich der Kernel-Versionen, sowie eine ausdrückliche Liste der Dienste, die auch ohne Neustart neu gestartet werden müssen.

Grenzen und Prüfbasis

Grundlage sind die Seite zu automatischen Updates in der Ubuntu-Server-Dokumentation und die Dokumentation des needs-restarting-Plugins von dnf-plugins-core, für den Kernel-Versionsvergleich zusätzlich uname(1). /var/run/reboot-required ist ein Debian/Ubuntu-spezifisches Verhalten des Toolings und keine Funktion von Kernel oder systemd; sein Fehlen auf einer anderen Distributionsfamilie sagt daher nichts aus. Stets auf den Vergleich der Kernel-Versionen zurückgreifen, der überall funktioniert. Die Prüfung selbst muss nicht rückgängig gemacht werden; der empfohlene Neustart oder Dienstneustart ist die eigentliche Massnahme und kann nach der Feststellung auf ein Wartungsfenster verschoben werden.