Ein Server kann wochenlang mit Sicherheitsupdates dastehen, die installiert, aber nicht aktiv sind, weil er auf einen Neustart wartet, den niemand eingeplant hat. Die Lösung: Lass dich über den Zustand „Neustart ausstehend“ bzw. „Updates ausstehend“ selbst alarmieren, nicht erst über den Ausfall, den er irgendwann verursacht. Unter Debian und Ubuntu wird dieser Zustand bereits auf die Festplatte geschrieben. Es braucht nur etwas, das ihn im Blick behält.
Dieser Fehlerfall ist unauffälliger als ein abstürzender Dienst. Automatische Sicherheitsupdates laden die Pakete herunter und installieren sie, aber der Kernel, die libc oder ein lange laufender Daemon nutzen weiterhin den alten Code im Arbeitsspeicher, bis sie neu gestartet werden. Der Fix liegt ungenutzt auf der Festplatte, und am Server sieht nichts falsch aus, bis die geschlossene Sicherheitslücke ausgenutzt wird oder der Neustart doch passiert, und zwar zum ungünstigsten Zeitpunkt, weil niemand ihn bewusst gewählt hat.
Woran Linux erkennt, dass ein Neustart erforderlich ist
Es gibt keinen POSIX-Standard für „diese Maschine muss neu gestartet werden“. Das ist komplett distributionsabhängig. Unter Debian und Ubuntu klinkt sich das Paket update-notifier-common in APT ein und schreibt eine Flag-Datei, sobald ein Paket fertig installiert ist, das einen Neustart erfordert (der Kernel, eine zentrale Bibliothek, systemd selbst):
$ cat /var/run/reboot-required
*** System restart required ***
$ cat /var/run/reboot-required.pkgs
linux-image-6.8.0-45-generic
libssl3
Die zweite Datei listet genau auf, welche Pakete das Flag ausgelöst haben. Das hilft dir bei der Entscheidung, ob ein Neustart bis zum Wochenende warten kann oder sofort nötig ist. Systeme der RHEL-Familie nutzen einen anderen Mechanismus (dnf needs-restarting -r), und needrestart geht auf beiden Familien noch weiter, indem es prüft, welche laufenden Prozesse noch auf gelöschte Dateien verweisen. Die Flag-Datei von Debian/Ubuntu ist aber das einfachste und am weitesten verbreitete Signal, weshalb die meisten Monitoring-Setups sie zuerst prüfen.
Warum Sicherheitsupdates mit unattended-upgrades liegen bleiben
Auf den meisten Debian- und Ubuntu-Servern läuft unattended-upgrades. Das Tool installiert Sicherheitspatches automatisch per Timer und wird in /etc/apt/apt.conf.d/50unattended-upgrades und /etc/apt/apt.conf.d/20auto-upgrades konfiguriert. Solange es funktioniert, denkst du nie darüber nach. Wenn es aufhört, etwa durch eine kaputte Abhängigkeit, ein zurückgehaltenes Paket oder einen still fehlgeschlagenen Cronjob, sammeln sich die Updates einfach an:
$ apt list --upgradable 2>/dev/null | grep -i security
openssl/jammy-security 3.0.2-0ubuntu1.15 amd64 [upgradable from: 3.0.2-0ubuntu1.14]
Ein paar aktualisierbare Pakete für ein oder zwei Tage sind normal, denn Mirrors synchronisieren sich und Timer laufen zeitversetzt. Wenn Sicherheitsupdates länger als etwa einen Tag uninstalliert herumliegen, bedeutet das fast immer, dass die Automatisierung, die sie installieren soll, stillschweigend ausgefallen ist, und nicht, dass nichts Wichtiges veröffentlicht wurde. Das ist ein anderes Problem als ein ausstehender Neustart und verdient einen eigenen Alert: Ein Server kann ganz ohne ausstehenden Neustart trotzdem auf ungepatchten Sicherheitslücken sitzen.
Alerts für Neustarts und Updates ohne eigenes Skript einrichten
Du kannst das selbst zusammenbauen, mit einem Cronjob, einem Prometheus-Textfile-Collector oder einem Nagios-Plugin, das auf /var/run/reboot-required prüft und das Ergebnis einem Check-Status zuordnet. Das funktioniert, ist aber pro Server ein weiteres Skript, das gepflegt werden muss. Außerdem brauchst du immer noch ein Ziel für den Alert und eine Möglichkeit, damit er dich nicht alle fünf Minuten anpiept.
InfraNest liefert beide Checks als integrierte Alerts unter Monitoring → Alert defaults mit, für jeden Server, auf dem der Agent installiert ist:
| Alert | Gemessen in | Standard | Wird ausgelöst, wenn |
|---|---|---|---|
| Ein Neustart steht aus | Tagen | Einmal, dann erneut nach 7 Tagen | Der Server meldet, dass er einen Neustart braucht, um Updates abzuschließen |
| Sicherheitsupdates warten | Stunden | Mehr als 0, für 24 Stunden | Updates seit einem Tag nicht installiert wurden |
Beide lesen dieselben Signale auf Distributionsebene, die oben beschrieben sind, also das Reboot-required-Flag und die Liste der aktualisierbaren Sicherheitspakete. Auf dem Server selbst musst du also nichts zusätzlich konfigurieren. Schalte einen der beiden Schalter einmal ein, und er gilt für jeden überwachten Server in der Organisation. Jeder einzelne Server kann später über seinen Tab Alerts & rules eigene Werte bekommen, ohne die übrigen zu beeinflussen.
NoteBeide Alerts werden speziell von Debian- und Ubuntu-Servern gemeldet, da dort die zugrunde liegenden Flag-Dateien liegen. Auf anderen Distributionen bleiben die Alerts ausgeschaltet, statt grundlos auszulösen.
Warum dich der Neustart-Alert nicht nervt
Ein Server, der auf einen Neustart wartet, tut das oft absichtlich. Niemand möchte, dass eine Produktivmaschine mitten im Deployment neu startet, nur weil vor einer Stunde ein Kernel-Update eingespielt wurde. Deshalb meldet sich der Neustart-Alert einmal, wenn das Flag zum ersten Mal auftaucht, dann noch einmal, falls der Server nach der von dir gewählten Anzahl an Tagen immer noch wartet, und bleibt dazwischen still. Ein Server, der bewusst bis zu einem ruhigen Wartungsfenster geparkt ist, unterbricht dich nicht ständig. Ein Server, der eine Woche lang vergessen wurde, bekommt einen zweiten Anstupser.
Der Alert für Sicherheitsupdates verhält sich anders, weil es keinen guten Grund zum Warten gibt. Er wird ausgelöst, sobald Updates 24 Stunden lang uninstalliert geblieben sind, und löst sich von selbst auf, sobald der Server aufgeholt hat. Beim Einspielen eines Patches gibt es nichts zu „planen“, deshalb ist keine zweite Schonfrist eingebaut.
TipWähle das Minuten- oder Stundenfenster realistisch statt aggressiv. Ein Schwellenwert, der beim allerersten Update auslöst, bringt dir nur bei, den Kanal zu ignorieren, in dem er landet. In unseren Hinweisen zum Alerting beim Monitoring erfährst du, wie du Alert-Fatigue generell vermeidest, nicht nur bei diesem Check.
Den Kreis mit Automatisierung schließen
Ein Alert, der um 2 Uhr nachts in Slack landet und auf einen Menschen wartet, erledigt nur die halbe Arbeit. Da es sich um ganz normale InfraNest-Alerts handelt, kannst du sie statt oder zusätzlich zu einer Benachrichtigung an eine Automatisierung übergeben: ein Ticket öffnen, wenn ein Server seit mehr als zwei Wochen auf einen Neustart wartet, jeden Montag eine Übersicht der wartenden Server in einem Channel posten oder eine Freigabe verlangen und den Server automatisch neu starten, sobald jemand zugestimmt hat. Der Alert sagt dir, dass etwas los ist. Die Automatisierung erledigt es dann tatsächlich, ohne dass du den Neustart von Hand ausführen musst.
Wenn du noch überlegst, was du auf einem Server sonst überwachen solltest, bevor es zum Ausfall kommt: Server-Metriken und Alerts behandelt CPU, Arbeitsspeicher, Festplatte und Last auf dieselbe Weise. Lies das am besten zusammen mit unserer umfassenderen Checkliste zur Absicherung deiner Infrastruktur, falls der Patch-Rhythmus Teil eines größeren Audits ist.
Aktiviere beide Alerts unter Monitoring → Alert defaults, und Server, die einen Neustart oder einen Anstoß zum Abschließen des Patchens brauchen, melden sich bei dir, statt zu warten, bis zuerst etwas kaputtgeht.
Häufig gestellte Fragen
#Bedeutet ein ausstehender Neustart, dass ein Sicherheitsupdate wartet?
Nicht unbedingt. Ein Neustart kann wegen eines routinemäßigen Kernel- oder Bibliotheksupdates ohne Sicherheitsfix ausstehen, und ein Sicherheitsupdate kann uninstalliert bleiben, ohne dass überhaupt ein Neustart nötig ist. Aus genau diesem Grund werden beide getrennt erfasst und gemeldet.
#Was passiert, wenn ein Server nie neu gestartet wird?
Bereits laufende Programme nutzen weiterhin die alte Version jeder aktualisierten Bibliothek bzw. des Kernels, einschließlich des Fixes, den ein Sicherheitsupdate gerade installiert hat, bis der Neustart tatsächlich erfolgt. Der Patch ist also technisch installiert, aber noch nicht wirksam.
#Warum funktionieren diese Alerts nicht unter RHEL oder CentOS?
Sie basieren auf Dateien und Paket-Metadaten, die Debian und Ubuntu speziell für diesen Zweck pflegen. Systeme der RHEL-Familie stellen dieselbe Art von Informationen über andere Tools bereit, die diese beiden Alerts derzeit nicht auslesen.
#Werde ich jeden Tag alarmiert, wenn ein Server absichtlich ungepatcht bleibt?
Nein. Der Neustart-Alert meldet sich einmal, wenn der Zustand erstmals auftritt, und noch einmal nach der von dir gewählten Anzahl an Tagen, danach bleibt er still. Der Alert für Sicherheitsupdates löst sich von selbst auf, sobald der Server aufgeholt hat, und wiederholt sich also nur, wenn das eigentliche Problem weiterhin besteht.
Mit einem kostenlosen Tool ausprobieren
War dieser Artikel hilfreich?
