Als Dienst schlug jeder Snapshot mit "cfs-lock 'storage-data' error: got
lock request timeout" fehl, waehrend derselbe Aufruf in der Shell
funktionierte.
Ursache war ProtectSystem=full in unserer eigenen Unit: das haengt /etc im
Namespace des Dienstes schreibgeschuetzt ein. pvesh fuehrt die Proxmox-API
im eigenen Prozess aus, der Snapshot-Task ist also ein Kindprozess von
pvesnap und erbt diese Einschraenkung. pmxcfs legt seine Sperren aber als
Verzeichnisse unter /etc/pve/priv/lock/ an - das mkdir scheitert, Proxmox
wiederholt es erfolglos und meldet am Ende einen Lock-Timeout statt eines
Rechtefehlers.
ProtectHome=yes war aus demselben Grund schaedlich: es blendet /root aus,
womit die SSH-Schluessel fuer die uebrigen Cluster-Nodes fehlen.
* Unit enthaelt keine Sandbox-Optionen mehr, mit Kommentar, warum nicht.
* Neu: pvesnap/preflight.py prueft root-Rechte, Schreibzugriff auf /etc/pve
und Sichtbarkeit von /root. Der Dienst schreibt das beim Start ins
Journal, "pvesnap check" zeigt es ebenfalls an - damit faellt so etwas
sofort auf, statt sich als Lock-Timeout zu tarnen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher stand im Fehlerfall nur der Exit-Status da ("cfs-lock ... error: got
lock request timeout"), nicht aber, was Proxmox davor protokolliert hat.
Fuer die Fehlersuche fehlte damit genau der interessante Teil.
* Schlaegt ein Task fehl, werden die letzten Zeilen des Task-Logs an die
Meldung angehaengt; identische Wiederholungen werden zusammengefasst
("trying to acquire cfs lock 'storage-data' ... (9x)").
* Die Meldung wiederholt nicht mehr VM und Snapshot-Namen, die der
Aufrufer ohnehin voranstellt.
Ausserdem ein Fehler in der Wiederholung: schlug der Task fehl, blieb der
Snapshot-Eintrag teils in der VM-Konfiguration stehen. Der zweite Versuch
lief dann in "snapshot already exists" - und diese Meldung verdeckte die
eigentliche Ursache. Ist der Snapshot bereits vorhanden, wird jetzt nicht
wiederholt und der urspruengliche Fehler gemeldet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auf einem echten Host schlugen Snapshots reihenweise mit
"cfs-lock 'storage-NAME' error: got lock request timeout" fehl.
Ursache: 'pvesh create .../snapshot' lief mit dem allgemeinen
Kommando-Zeitlimit von 60s. Genau so lange wartet Proxmox aber auf den
Storage-Lock. Lief der Aufruf in unser Zeitlimit, ging es mit der naechsten
VM weiter, waehrend der Task noch lief - und die naechste VM scheiterte
dann an derselben Sperre. Eine VM konnte so einen ganzen Lauf umwerfen.
* Snapshot-Aktionen laufen jetzt mit dem langen task_timeout statt mit dem
kurzen Zeitlimit fuer Lesezugriffe.
* Ohne UPID in der Antwort wird ersatzweise gewartet, bis der Gast nicht
mehr gesperrt ist, statt sofort weiterzumachen.
* Sperr-Fehler gelten als voruebergehend und werden 'retries'-mal mit
'retry_delay' Abstand wiederholt; echte Fehler wie "storage does not
support snapshots" nicht.
* Neu: 'pause_between' fuer eine Pause zwischen zwei Gaesten.
Ausserdem: Kommentare hinter einem Wert ("retries = 2 # ...") wurden nicht
abgeschnitten und machten die Konfiguration ungueltig - das eigene
Beispiel war davon betroffen. 'description' bleibt bewusst unangetastet,
damit ein '#' in der Beschreibung erhalten bleibt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nach dem Speichern musste man bisher in die Konsole wechseln, um die
Konfiguration mit "systemctl reload pvesnap" scharf zu schalten. Die
Gruppenliste kann das jetzt selbst:
* 'r' laedt den Dienst neu; ungespeicherte Aenderungen werden vorher zum
Speichern angeboten, ein gestoppter Dienst zum Starten, und wenn das
Neuladen scheitert, wird ein Neustart angeboten.
* Nach 's' fragt der Editor direkt, ob neu geladen werden soll.
* Die Kopfzeile zeigt laufend den Zustand des Dienstes.
* Die Tastenleiste bricht auf schmalen Terminals auf zwei Zeilen um,
statt hinten abgeschnitten zu werden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Haelt __pycache__, Sicherungskopien der Konfiguration und Laufzeitdateien
(state.json, Sperrdateien) aus dem Repository heraus.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5