Backup-Job lässt sich nicht beenden -- warum?

[whiterabbit]

Hallo.
Heute Nacht ist ein Backup-Job auf eine Diskstation aus irgendwelchen Gründen hängen geblieben (Laufzeit >14 Stunden ist unrealistisch). Leider kann ich den Job nicht killen. Zwar sehe ich:

aber das lässt sich nicht stoppen.
Natürlich habe ich danach bereits die VM heruntergefahren und es auf dem harten Weg versucht:

ps aux |grep vzdump
kill -9 38425

aber dieser Prozess läuft weiterhin:

38782    task UPID:pve:0000977E:12D1A6BD:6137C4C4:vzdump::root@pam:

und lässt sich auch nicht killen. Ich würde den Server nur ungerne neu starten -- daher die Frage, wie ich den Prozess sonst noch beenden kann?
Danke.

 

[Stefan_R]

In welchem Status befinden sich denn die dazugehörigen Prozesse? (Spalte 'S' in 'top' oder 'htop' - F5 in htop ist sehr nützlich zum finden) Auf welche Art Ziel wird das Backup geschrieben? (lokaler mount, NFS, SMB, ...)

 

[whiterabbit]

Spalte S zeigt dein "D" und das Backup wurde gestern Nacht auf ein NFS-Share eine Diskstation geschrieben.
Allerdings läuft nun auch nur noch ein einziger Prozess, der "vzdump" im Namen träg und zwar der o.g.

ps aux |grep vzdump
38782    task UPID:pve:0000977E:12D1A6BD:6137C4C4:vzdump::root@pam:

Übrigens: Das Problem fiel heute Morgen nur deshalb auf, weil die VM nicht erreichbar war (es handelt sich hier um unsere Nextcloud). Ein Blick auf den Proxmox-Host zeigte dann, dass die VM dieses "Disketten-Symbol" (lock) hatte und das Backup scheinbar immernoch lief -- was aber offenbar seit Stunden nicht mehr vorwärts ging.

 

[Stefan_R]

"D" steht für einen "dead" process, das heißt der task wartet auf einen syscall. Bei einem NFS share kann das recht einfach passieren wenn z.B. die Verbindung abbricht.

Aus einem steckengebliebenen "D" state kommt man nur durch einen reboot wieder heraus. Das ist leider ein feature des Linux Kernels, und der integration des NFS clients.

 

[whiterabbit]

Ok danke ... dann ist die nächste Frage, was das Backup heute Nacht mit diesem Prozess macht? Stören die sich? Sollte der Server also den reboot vorher durchgeführt haben?

 

[Stefan_R]

Nachdem der Task an sich noch aktiv ist (mit einer UPID), also ja wahrscheinlich auch noch in der Task-List aufscheint, ist davon auszugehen, dass auch entweder das VM oder das vzdump lock noch aktiv ist. Dann kann man keinen neuen Backup-Vorgang starten.

Ich würde auf jeden Fall vorschlagen, genau zu inspizieren weshalb es zu dem dead-state gekommen ist - e.g. auf jeden Fall logs durchschauen, am PVE und am NFS server; Netzwerkverbindungen prüfen; Szenerio nachstellen; etc....

 

[whiterabbit]

Ok, die Diskstation ist down ... warum ist im Moment nicht klar. Kann ich erst morgen ermitteln. Aber das wird die Ursache gewesen sein.
Ich hatte es zwischendurch schon mit "qm unlock 401" versucht, um die VM immerhin neu starten zu können. Sie läuft auch wieder ...