Ein häufiger stiller Fehler: Das Sicherheitsupdate ist eingespielt, die Version stimmt, die Meldung ist abgehakt und der betroffene Dienst benutzt weiterhin die alte Bibliothek, weil er sie beim Start geöffnet hat und seither nicht neu gestartet wurde.
Es entsteht eine Lücke zwischen Papierlage und Wirklichkeit: Die Paketliste sieht sauber aus, der laufende Prozess ist verwundbar. Besonders unangenehm bei Bibliotheken, die viele Dienste einbinden, eine Aktualisierung, viele Prozesse, die nichts davon merken.
Sichtbar machen#
sudo apt install needrestart
# Was läuft noch mit ersetzten Dateien?
sudo needrestart -b
# NEEDRESTART-SVC: Dienste, die neu starten sollten
# NEEDRESTART-KSTA: 0 = Kernel aktuell, 1 = Neustart nötig, 3 = neuer Kernel installiertOhne Zusatzpaket geht es auch:
# Prozesse mit gelöschten, aber noch offenen Dateien
sudo lsof -n +c 0 2>/dev/null | grep -E 'DEL|deleted' | awk '{print $1, $2}' | sort -u
# Läuft der laufende Kernel noch dem installierten hinterher?
uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2, $3}'Der Unterschied zwischen Dienst und Kernel#
Dienstneustart genügt bei Bibliotheken (OpenSSL, glibc-nahe Fälle ausgenommen), Interpretern und der Anwendung selbst. Er dauert Sekunden.
Neustart der Maschine ist nötig bei Kernel, Mikrocode und bestimmten systemweiten Bibliotheken. Er lässt sich nicht ersetzen, auch nicht durch Wunschdenken.
# Debian/Ubuntu markieren einen nötigen Neustart mit einer Datei
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required*Ein systemctl restart ssh trennt bestehende Sitzungen nicht. Trotzdem gilt: vorher eine zweite Sitzung offen halten und danach mit einer dritten prüfen, ob eine neue Anmeldung funktioniert. Wenn im selben Zug eine Konfigurationsänderung eingespielt wurde, ist das der Moment, an dem sie erstmals greift, dieselbe Vorsicht wie in Passwort-Login abschalten.
Automatisch, aber vorhersehbar#
unattended-upgrades kann Dienste selbst neu starten und, wenn gewünscht, die Maschine. Beides ist besser als „nie“, aber es gehört bewusst gesetzt:
// /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";
# /etc/needrestart/needrestart.conf — Dienste ohne Rückfrage neu starten
$nrconf{restart} = 'a';
Wer keine automatischen Neustarts will, braucht die Gegenmaßnahme: eine Erinnerung, die ankommt.
# Wöchentliche Meldung, wenn etwas aussteht (schweigt sonst)
cat >/etc/cron.weekly/neustart-noetig <<'SH'
#!/bin/sh
[ -f /var/run/reboot-required ] || exit 0
printf 'Neustart ausstehend seit: %s\n%s\n' \
"$(stat -c %y /var/run/reboot-required)" "$(cat /var/run/reboot-required.pkgs 2>/dev/null)" \
| mail -s "Neustart ausstehend: $(hostname -s)" [email protected]
SH
chmod +x /etc/cron.weekly/neustart-noetigContainer haben dasselbe Problem, anders#
Ein Container startet mit dem Image, das er hat. Ein Sicherheitsupdate im Basis-Image wirkt erst nach einem Neubau und Neustart, apt upgrade im laufenden Container ist der falsche Weg, weil die Änderung beim nächsten Start verschwindet. Der richtige steht in Container-Images aktuell halten.
In den Ablauf einbauen#
Der Neustart gehört ans Ende jedes Wartungsfensters, mit derselben Prüfung wie der Rest: Dienst läuft, Anwendung antwortet, Protokolle sind ruhig (Wartungsfenster und der Weg zurück). Und wenn eine Meldung nach dringender Behandlung verlangt: Erst nach dem Neustart ist der Punkt wirklich erledigt, vorher steht er nur in der Paketliste.
Der Neustart, den niemand traut#
Hinter vielen ausgelassenen Neustarts steckt keine Nachlässigkeit, sondern eine begründete Sorge: Man weiß nicht sicher, ob die Maschine sauber hochkommt. Dienste, die von Hand gestartet wurden, ein Mount, der nicht in der fstab steht, eine Firewallregel, die nur im laufenden Betrieb existiert, all das fällt erst beim Booten auf, und dann zur ungünstigsten Zeit.
Genau deshalb ist der geplante Neustart wertvoller als der vermiedene: Er findet diese Dinge zu einem Zeitpunkt, den man selbst gewählt hat. Wer seit Monaten nicht neu gestartet hat, sollte den nächsten Termin bewusst legen, mit Sicherung davor, offener Konsole beim Anbieter und einer kurzen Liste dessen, was danach laufen muss.
# Vor dem Neustart: Was ist aktiviert, startet also von selbst?
systemctl list-unit-files --state=enabled --type=service --no-legend | awk '{print $1}'
# Gegenprobe danach: Was läuft, war aber nicht aktiviert?
systemctl list-units --type=service --state=running --no-legend | awk '{print $1}'Die Differenz beider Listen ist die eigentliche Antwort auf die Frage, warum man sich vor Neustarts fürchtet und sie lässt sich abarbeiten.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
