Proxmox

Nachts um 6 startet mein ganzer Proxmox-Server neu – warum, und wie man es kontrolliert

unattended-upgrades darf nach Kernel-Updates um 06:00 rebooten – Host samt allen VMs. Nachweis über last -x, und drei Wege, es zu zähmen.

Michael Mackedanz

— 2 Min. Lesezeit
Teilen

Irgendwann fällt dir auf, dass früh morgens kurz alles weg war. Kein Stromausfall, kein Absturz. Es ist eine Debian-Voreinstellung, die in keinem Proxmox-Tutorial vorkommt.

TL;DR

unattended-upgrades auf dem Proxmox-Host darf nach einem Kernel- oder Sicherheitsupdate selbstständig rebooten – Standardzeit 06:00. Der ganze Host geht neu, und mit ihm jede VM und jeder Container. Nachweisen lässt es sich mit last -x reboot. Du hast drei Optionen: so lassen, die Zeit verschieben, oder abschalten und selbst steuern.

Das Symptom

Ein Dienst war früh am Morgen für ein, zwei Minuten nicht erreichbar. VMs und Container zeigen eine Uptime von wenigen Stunden, obwohl du seit Wochen nichts angefasst hast. In den Logs der Anwendung selbst steht nichts Auffälliges. Und weil es nur sporadisch passiert – nämlich nur, wenn ein reboot-pflichtiges Update anlag – suchst du beim nächsten Mal wieder von vorn.

Wo es herkommt

Auf dem Proxmox-Host, in /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "06:00";

Übersetzt: Wenn ein unbeaufsichtigtes Update – typischerweise ein neuer Kernel – einen Reboot verlangt, führt der Host ihn um 06:00 selbst aus. Ohne Rückfrage, ohne Notification. Die unbeaufsichtigten Updates selbst laufen über die üblichen systemd-Timer (apt-daily-upgrade.timer); der Reboot ist die Folge davon.

Bei mir ist das nachweislich scharf: last -x reboot zeigt einen sauberen Neustart um 06:00–06:03 an dem Tag, an dem der Kernel von 7.0.14-12-pve auf -14 ging – exakt auf die konfigurierte Minute. Ältere Reboots in der Liste liegen mitten am Tag (13:20, 18:01) – das waren manuelle. Der 06:00-Eintrag ist der Fingerabdruck dieses Mechanismus.

Wie du es nachweist

last -x reboot | head          # Muster: Neustarts exakt um 06:0x
ls -t /var/log/unattended-upgrades/
journalctl --since "yesterday 05:55" --until "yesterday 06:15"

Findest du dort einen Reboot um kurz nach sechs plus vorher einen unattended-upgrades-Lauf mit einem Kernelpaket, ist die Sache klar.

Die drei Optionen

So lassen. Nicht die schlechteste Wahl. Sicherheitsupdates inklusive reboot-pflichtiger Kernel werden ohne dein Zutun eingespielt. Der Preis ist der unangekündigte Ausfall zur Unzeit.

Zeit verschieben. Automatic-Reboot-Time auf einen Zeitpunkt setzen, an dem garantiert kein Backup, keine große Schreiblast und keine OTA läuft. Ändert nichts am „ohne Vorwarnung", nimmt aber die Kollision mit anderen Nachtjobs raus.

Abschalten und selbst steuern. Automatic-Reboot "false". Der Host installiert dann weiter automatisch, rebootet aber nicht mehr von allein – du siehst „Reboot required" und entscheidest, wann. Mehr Kontrolle, mehr Handarbeit.

Warum das im Homelab besonders zählt

Um 06:00 wird alles hart mitgerissen: ein Container mitten im Schreibvorgang, ein Backup, das sich verspätet hat, ein Zigbee-OTA-Update. Ein sauberer vzshutdown/qmshutdown läuft zwar davor, aber alles, was zu lang braucht, wird abgewürgt.

Und es gibt einen Zweitschlag, der garantiert Zeit kostet: nach dem Reboot brauchen Funk-Anbindungen Minuten zum Resynchronisieren. Bei mir standen nach einem Host-Neustart drei DECT-Heizungsthermostate auf unavailable, HA warf drei „missing entity"-Repairs. Ursache war nicht der Reboot als solcher, sondern dass die DECT-Neuanmeldung an der FritzBox länger dauerte als das Polling-Intervall der Integration erwartet. Ein Reload der Integration holte einen davon sofort zurück, die anderen zwei kamen nach ein paar Minuten Warten von selbst wieder. Wer das nicht als Reboot-Nachwirkung erkennt, jagt zwei Stunden einem Phantom hinterher.

Checkliste

  • „War heute Nacht kurz alles weg?" → zuerst last -x reboot auf dem Host, auf ein 06:0x-Muster schauen
  • 50unattended-upgrades auf Automatic-Reboot prüfen
  • Entscheiden: so lassen / Zeit ans backupfreie Fenster schieben / abschalten und manuell
  • Nach jedem Host-Reboot: HA-Repairs und unavailable-Entitäten checken, Funk-Integrationen ggf. einmal reloaden statt Fehler zu suchen
  • systemctl --failed in unprivilegierten LXCs zeigt oft apparmor / sys-kernel-config.mount – das ist normal und nicht reboot-bedingt

Verwandte Notiz: Warum deine HA-Integration das Gerät im IoT-VLAN nicht findet. — Welche Schicht im Stack sich automatisch aktualisiert und welche du bewusst von Hand fährst (HA Core, HAOS, Supervisor, LXC-Pakete, Container-Images, Zigbee-Firmware) – die komplette Tabelle steht im Guide. Dann hier entlang.

Weiterlesen