Proxmox auf Intel NUC: Unregelmäßiger Freeze bei nächtlichem Backup

In sehr unregelmäßigen Abständen friert mein Proxmox server während des nächtlichen Backups ein.
Der System Log hört dann einfach auf
image

und der Status vom Backupprozess ebenfalls

Der Freeze ist so ziemlich immer an der gleichen Stelle des Backupprozesses (zumindest im ähnlichen Prozentbereich der gleichen VM). Auf dieser VM läuft Home Assisstant. Mal geht es für Tage und Wochen gut und manchmal passiert es in Nächten kurz hintereinander. Ein Muster konnte ich noch nicht feststellen. Auf den Server komme ich dann nicht mehr - weder per SSH noch WebUI. Ping ging glaub ich noch (hatte ich anfangs mal probiert). Abhilfe schafft dann nur noch ein manuelles Ausschalten und wieder Einschalten am Gerät.

Den Intel e1000e NIC Offloading Fix hatte ich bereits vor einiger Zeit durchgeführt.

Ich habe schon online gesucht und nichts passendes gefunden und womöglich nur nicht mit den richtigen Stickworten gesucht.

An welcher Stelle könnte ich noch nach Ursachen suchen oder was könnte die Ursache sein?

System:
image

Ich hab sowas ähnliches gehabt / hab es teilweise immer noch.
Da war der RAM ein Problem…

Wie hast du es auf den RAM eingrenzen können? Meine Riegel sind ca. 2 Jahre alt - 2x 8GB… viel Auswahl für die älteren NUCs gibt es ja nicht…

Hallo,

kenne mich mit der NUC-Plattform nicht sooo aus.

Ich haette zwei Ideen fuer Dich:

a) Wenn z.B. ein Linux beim Booten stecken bleibt und man _nur_ am Monitor sitzt, ist man ziemlich gea… , weil da nix steht. _Ausser_ man hat vorher bei grub eine Umleitung auf /dev/ttySx vorgenommen, dann kann man seriell lesen, warum das System stecken blieb, sprich mehr Infos.

Vllt. kann der NUC bevor der Freeze kommt etwas noch auf die /dev/ttySx schreiben?

Wenn Du, da Proxmox aud Debian fusst, unter /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 consoleblank=0”

ergaenzst, und ein update-grub vornimmst, neu bootest, koenntest Du beim naechtlichen freeze mitlesen?

#GRUB_CMDLINE_LINUX_DEFAULT=„quiet“

muss dafuer wech.

Auch sehr nuetzlich, weil Du dann gar Grub auf der seriellen Schnittstelle hast.

GRUB_TERMINAL=console

Zweiter Vorschlag

b) Da Linux und ab kernel 4.x alle module in der initrd, koenntest Du vllt. die HD einfach auf ein anderes Board stecken, sicher miuesstest Du die NIC anpassen, fstab nicht. Cest ca. Dann einfach zwei Tage laufen lassen, oder halt das Backup vorziehen. So wuesstest Du, ob deine Installation korrumpiert oder evtl. nur das RAM defekt ist(?).

[ c) Wenn, wie im Forum auch eingeworfen, RAM, dann waere ein MEM-TEst auch moeglich, doch dann steht der Server fuer paar Stunden.]

Viel Erfolg.

ELindemann

Hallo!

Danke für die Vorschläge. Serielle Schnittstelle sagt mir prinzipiell was. Wie ich die auslese/dort mitlese übersteigt leider mein aktuelles Wissen.
Auf ein anderes Board wird mangels alternativem Board auch nicht möglich sein.

Die Freezes treten sehr unregelmäßig auf, mal läuft alles für 1-5 Wochen ohne Probleme (und jede Nacht das Backup), dann sind es mal nur 2 oder 3 Tage und dann läuft es wieder für über 1 Woche.

Wahrscheinlich werde ich mal den MEM-Test machen - dann fehlen halt ein paar Stunden der Aufzeichnungen, aber die fehlen ja auch nach den Freezes, bis ich morgens sehe, dass es mal wieder soweit ist…

Habe ich mit memtester das falsche Tool gefunden? Du scheinst dich auszukennen und kannst evtl. noch Tipps für die Durchführung des MEM-Tests geben?

Besten Dank!

Hallo steveson,

@Board, Du hast @home kein anderes Board oder eni 08/15 Rechner?

Really? Da die NUCs eher klein sind, mit 2,5Zoll HDs (?) laufen, langte auch ein NB.

Hat der NUC eine serielle Schnittstelle?

Wahrscheinlich nicht. Wohl dann eine USB. Das sollte aber die Show nicht stoppen.

Ich habe bei den HPs immer eine klassiche COM/DB9 Schnittstelle, daran geht ein verdrehtes serielles (Kabel, RX-TX jeweils gedreht), dieses Kabel kaeme dann an ebenso FB9 dren. Wenn Du weder noch hast, also nirgedns DB9 Schnittstelle, muesste man nachdenken. Es gibt USB/DB9 Konverter fuer billiges/faires Geld (Ali ist billiger), doch die setzen halt eine DB9-Schnittstelle voraus.

Lies, die serielle Schnittstelle ist evtl. jetzt (auch Feiertage, Bestellung/Lieferung) schwer umzusetzen.

Daher, mein Tipp anderes Board. In wlechem Raum wohnst Du? → PM

Wenn nahe, kann ich Dir einen 08/15 PC leihen.

Doch nochmal: Deine Boot-HD wird auf jedem NB/PC sofort booten. EInzig die NIC ist anzupassen.

@MEMTEST

Jedes Distri-CD/DVD-ISO-Image hat einen memtester, selbserklaerend, aber auch zeitintensiv.

Daher Umbau auf eine andere HW und schauen, was passiert. Das Ergebnis bringt Dich viel weiter, Du wuesstest, ob deine InstallationOK ist. Wenn nicht, abhaken, neu installieren, vorher /ect und die VM-Configs sichern.

Zur Not ein Riegel (bootet dann ein NUC?)?

Also nur 8G RAM, so what, zwei Tage halt weniger VMs etc.., doch dann haettest Du auch ein anderes setup an VMs.

Hast Du Kabelstrecken an den HDs?

Oder stecken die HD auf fixen Anschluessen auf der Platine. Wenn Kabel, wuerdest Du DMA/CRC Fehler sehen, schon vorher. Und wann dann das Backup laeuft, also viel Traffic generiert wird, ist es dann zu viel auf einmal(?).

Nochmal, anderes Board. :wink:

Gruss

ELindemann

Hallo!

Im NUC werkelt eine 512GB mSATA SSD. Hab einen USB-Adapter dafür, könnte damit wahrscheinlich an einem Uralt-Notebook mit nur 4GB RAM booten, falls das was bringt. Oder an einem älteren MacBook, was glaub ich schon wieder schwieriger wird.

Vorübergehend erst einen, dann den anderen RAM-Riegel rausnehmen und laufen lassen könnte ich auch probieren. Werde mal schauen, welche VMs und LXC ich vorübergehend weniger laufen lassen kann um RAM zu sparen. Und zur Not ist der SWAP groß genug…

Danke für deine ausführlichen Ausführungen und Gedanken dazu! :+1:

Mal das Tool Memtest86+, aus dem GRUB-Startmenü oder einen Live-USB-Stick (z.B. Debian oder Ubuntu) ausgeführt? Am besten über Nacht

Noch nicht - kommt auf die Liste.

Hallo mochmals,

noch ne andere Idee, solltest Du noch einen NVME Stick rumliegen haben ;-), dann ziehst Du den akt. raus installierts gerade mal neu, gnaz frisch + Backup und paar Dummys, damit das backup auch paar Runden dreht.

Wenn dann ein touch down erfolgt, also wieder ein Abbruch, so ist es die HW, zumindest nicht die Installation. Da waere _mir_ (wenn ich betroffen waere) weitaus lieber, denn die HW ist schnell geholt, (wahrscheinlich das RAM) und fertig ist die Laube. Jedoch das Syste soweit zu bringe, aufzubauen (wenn dein Backup das nicht erbringt, also baremetall-backup), das kann man odch auch priv nicht zahlen, reine Lebenszeit. Dann kauft man :slight_smile: sich frei, mit ein/zwei Riegel. Aber das System muss nicht neu aufgezogen werden. Viel Erfolg.

ELindemann

Hallo!
Das klingt, als wäre dir das Thema länger als gedacht im Kopf rumgespukt.

Ich hab noch eine mSATA-SSD rumliegen, die vorher drin war. Ich werde es mit der mal neu aufsetzen, dann die Backups einspielen und laufen lassen. Mal sehen was dann passiert.

Vom Verhalten her kann ich mir schon vorstellen, dass es ein RAM-Thema sein könnte. Parallel werde ich auch nach neuen RAM-Riegeln schauen - hier gilt wahrscheinlich auch: Haben ist besser, als brauchen.

Danke für deinen zusätzlichen Input und guten Start in die Woche! :slightly_smiling_face:

@im Kopf rumspuken

Nicht ganz, ich hatte mal (aus Dummheit) sowas aehnliches in einer vm unter debian. Da war ich so doof statt virtio, den SCSI NCR8xx/5xy (drauf fusst der SCSI-Treiber unter qemu/kvm) einzustellen. Dieser Chip war mal vor mehreren Dekaden 08/15-SCSI Controller von NCR/Symbios, in 10/20/40 MByte/s Versionen.

Hatte bei der vm einen freeze aus dem Nichts, keine Chance auf irgendeinen Hinweis, keine qemu-ttySx Ausgabe, kein gar nix. F… F… F… (zudem Mailserver). Irgendwann fiel der Groschen. Warum ich das (ein einziges Mal, nie wieder) eingestellt habe, kann ich nur mit unendlicher Dummheit erklaeren; die Performance war aehnlich. Aber paar Monate unguttes Leben. :wink:

Insofern kann ich deinen Zustand gut nachvollziehen, dass man endlich wieder stabile Verhaeltnisse hat/haben moechte.

Ich hatte auch schon zwei Mal auf den HP-Servern ECC-Fehler; die wurden/werden aber zuverlaessig detektiert, eben auch angesagt, welcher Riegel Stress macht, mit RTFM der HW kriegt man raus, was man ziehen muss. Bei Login kriege ich eine Nachricht, ebenso alle 2h wird der Status ueberprueft.

/usr/bin/edac-util → edac-util: No errors to report.

hilft, sofern das MB die HW dazu auch hat.

Sag bitte Bescheid, was Dir das Spiel so verdirbt/verdorben hat.

Gruss

ELindemann

1 Like

Schaue mal ob im BIOS irgentwelche Energiespar-Einstellungen für die CPU aktiv sind und schalte die ab.

Das war bei meinem AMD das Problem mit ständigen Freeze in der Nacht - seit dem kein einziges Mal vorgekommen.

Danke dir! Kommt ebenfalls auf die Liste nach ganz oben. :+1: