Commit Graph
4 Commits
Author SHA1 Message Date
duffyduckandClaude Opus 5 1be13ad294 Sandbox-Optionen aus der systemd-Unit entfernen
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>
2026-07-31 02:16:12 +02:00
duffyduckandClaude Opus 5 e9aeaf9e62 Snapshot-Laeufe gegen cfs-Sperren des Storages absichern
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>
2026-07-31 01:54:59 +02:00
duffyduckandClaude Opus 5 8f1bf037cd TUI: Dienst per Taste 'r' neu laden
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>
2026-07-31 01:47:04 +02:00
duffyduck 87f1b4d555 first commit 2026-07-30 16:52:58 +02:00