timeout waiting for systemd

[antiager]

Hallo Forum!

Auf einem Pve 9 der die ganze Zeit unauffällig lief wurde eine VM (debian) plötzlich langsam und ließ sich nur durch sigkill beenden.

Dann startete Sie nicht mehr - time out waiting for systemd - erst nach einem reboot des Hosts ließ sie sich wieder starten.

Das gleiche passierte in den nächsten Tagen mit zwei anderen VMs (debian und windows).

Die KI meint "überlastung des ZFS?" man soll in den Einstellungen der Festplatten "Asynchrone IO" auf "threads" stellen!?

Habt ihr dazu Ideen?

Danke euch im voraus!

 

[Bu66as]

Das timeout beim Start kommt meistens daher, dass der alte qemu-Prozess noch nicht sauber weg ist und der scope deshalb blockiert. Deshalb hilft nur ein Host-Reboot. Das Problem ist das Hängen davor. Schau ins journal vom Host für den Zeitpunkt wo's langsam wurde, ob sowas wie task ... blocked for more than 120 seconds oder ZFS-Meldungen auftauchen. Dann siehst du ziemlich schnell ob's wirklich am Storage klemmt oder woanders.

Was mich interessiert: Wieviel RAM hat der Host, wieviel kriegen die VMs insgesamt, und hast du ein ARC-Limit gesetzt? Ohne Limit nimmt sich der ARC die Hälfte vom RAM, und wenn die VMs dann auch noch alles wollen wird's eng. Was macht der IO-Delay-Graph auf dem Node wenn es passiert?

aio auf threads würde ich erst anfassen wenn klar ist dass es an io_uring hängt, sonst rätst du nur rum. Poste am besten mal pveversion -v und die Config von einer der betroffenen VMs (qm config <vmid>).

 

[ThoSo]

Die KI meint "überlastung des ZFS?" man soll in den Einstellungen der Festplatten "Asynchrone IO" auf "threads" stellen!?
Habt ihr dazu Ideen?

Klar, ist immer ein Gute Idee die KI zu fragen - Menschen brauchen ja auch keine Infos zur Hardware auf der das ganze läuft. Auch nicht wie das konfiguriert ist. ZFS, Sicher läuft.
Meine Glaskugel fragt, ob da vielleicht auch noch ein bischen mehr Info rüberkommen könnte.
Danke vorab.

 

[celemine1gig]

Klar, ist immer ein Gute Idee die KI zu fragen - Menschen brauchen ja auch keine Infos zur Hardware auf der das ganze läuft. Auch nicht wie das konfiguriert ist. ZFS, Sicher läuft.
Meine Glaskugel fragt, ob da vielleicht auch noch ein bischen mehr Info rüberkommen könnte.
Danke vorab.

Man sieht eindeutig, dass du keine Ahnung hast. Fragen nach Details stellen? Unverschämt. Du könntest ja auch einfach mal die Lösung präsentieren. Würde uns allen das Leben erleichtern.

@antiager
Und nun nochmal ein wenig ernster:
Da du ja anscheinend schon gemerkt hast, dass dich die KI wohl nicht so ganz retten wird...
Wenn jemand deine Anfrage(n; plural, weil das generell gilt) sinnvoll beantworten soll, so gilt immer: Es kann (fast) nie genug Details geben.
Also am besten exakte Daten zur verwendeten Hardware, Software und Config liefern. Das Tüpfelchen auf dem "i", wenn das ganze noch lesbar formatiert präsentiert wird.
Im Idealfall fällt einem der vielen schlauen Leute hier im Forum dann DAS wichtige Detail auf und dir kann geholfen werden.
In der Realität bräuchte die KI für sinnvolle Antworten auch diese Details, aber löst das Ganze im Zweifelsfall halt durch Haluzination. Bei echten Menschen eher selten der Fall. Jedenfalls im Kontext von Lösungen.

 

[ThoSo]

Wäre der Antiager ein New Member würde ich das auch anders ausdrücken, aber seit 2020 im Forum, über 200 Beiträge und dann weiss man das immer noch nicht?
Ich checke auch nicht seine alten Posts nur um wage eine Idee zu bekommen was er da betreiben könnte. Geld ist Zeit und Zeit ist Geld.

 

[fiona]

Hi,
es ist empfohlen, in so einem Fall qm stop ID zu benutzen, statt direkt den Prozess zu killen, weil dann wird noch mehr cleanup gemacht. Was sagt systemctl status ID.scope im Fall wenn das Timeout auftritt? Für beide Kommandos die numerische ID benutzen, statt den Platzhalter.

Und wenn die VM hängt, was sagt qm status ID --verbose?

 

[antiager]

200 Posts hab ich schon gemacht! Hätte ich nicht gedacht.

Die Infos sind zu dünn da gebe ich euch recht.
Das resultiert aus der irrigen Annahme, das es sich um einen vielleicht wohlbekannten Fehler handeln könnte der eine einigermaßen einfache Antwort/Problemlösung hat.
Ich habe diesen Fehler trotz meines fortgeschrittenen Alters vorher noch nie vorher gesehen bzw. hätte ich Berührung damit gehabt.

Die KI zu fragen halte ich jetzt nicht für so schlimm, so lange man nicht blind alles sofort ausführt was die KI einem da so rät.
Deshalb habe ich das ja auch erstmal hier gepostet.

Ich hoffe nach dieser Erläuterung stehe ich jetzt nicht mehr ganz so doof da!

Bei dem betr. PVE9 handelt es sich um einen Dellserver mit Raidcontroller im HBA-Mode mit 128 KB Ram, Filesystem ZFS, die Daten liegen auf Enterprise SSDs im Raid 10.

Die Maschine läuft in dieser Konfig schon einige Jahre weitgehend Fehlerfrei.

Im akuten Fall erfolgte die versuchte Fehlerbehebung jedesmal telefonisch mittels "Fernsteuerung" des Kunden, das ist ein weiterer Grund für die spärlichen Angaben.

qm stop ID wurde zunächst versucht.

Arc Limit ist gesetzt:
cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min)'
c_min 4 5368709120
c_max 4 11811160064
size 4 11865634352
ich hoffe das beantwortet die Frage nach dem Arclimit - sonst bitte Info

IO delay maximal 1 oft 0,4 (im akuten Fall konnte ich das nicht prüfen als der Fehler aufgetreten war).

Die Ram Auslastung zeigt der PVE Host im normalbetrieb (5 aktive Vms Windows und Linux) bei 60 %

Die VMs laufen allesamt flüssig sodass gefühlt kein Engpass zu existieren scheint

Ich hoffe die Infos helfen ein bisschen.

Ich bedanke mich für eure Mühe!