[SOLVED] Nextcloud Proxmox Absturz

[mueller]

Hallo,
ich bin relativ neu und habe ein Frage bzw. Bitte:

Zur Situation:
Auf einem kleinen Server habe ich hier zu Hause eine Proxmox VE Installation. Darauf lediglich eine VM mit einer Nextcloud-Installation auf Debian-Basis.
Auf einem zweiten kleinen Server läuft ein ProxmoxBackServer, einmal in der Nacht wird die VM darauf gesichert.

Das läuft auch alles wie gewünscht.

Das Problem:
Oft – nicht immer – ist es so, dass die VM sich nachts aufhängt.
D.h. Nextcloud ist nicht mehr erreichbar. Auch das darunter liegende Debian ist nicht mehr per ssh zu erreichen.
Das passiert nicht jede Nacht, manchmal läuft die Installation auch ein, zwei Tage durch - länger aber nicht.

Die Proxmox-Installation selber läuft stabil.
Nachdem ich diese per ssh neu gestartet habe, ist auch Nextcloud wieder einsatzbereit.

Meine Frage bzw. Bitte:
Kennt jemand das Problem und kann mir einen Tipp geben, was ich tun kann?
Wahrscheinlich können die Ursachen ja mannigfaltig sein.
Ich weiß aber nicht, wo ich welche logs zu dieser Problematik einsehen kann, um nähere Angaben zu machen.

Für einen Tipp, der mir da weiterhilft wäre ich dankbar.

 

[mira]

Ist in der VM persistent Journal aktiv? Wenn ja, bitte das Journal von ein paar Minuten vor dem Crash bis nach dem Reboot (ebenfalls so ~10 Minuten) bereitstellen. Dies kann mit journalctl --since "2022-08-XX HH:MM:SS" --until "2022-08-YY HH:MM:SS" > journal.txt in ein Textfile mit dem Namen journal.txt gespeichert werden. Dieses bitte hier anhängen.
XX/YY mit dem jeweiligen Tag ersetzen und HH mit Stunden, MM mit Minuten und SS mit Sekunden ersetzen.

 

[mueller]

Erstmal vielen Dank für die Hilfsbereitschaft.

Ich frage mich gerade, wo ich den genauen Zeitpunkt des Crashes einsehen kann, sodass ich die genaue Zeit eingeben kann.
Das passiert immer nachts

 

[Dunuin]

Monitoring Tools wie Zabbix sind für so etwas praktisch. Damit kannst du etliche Zustände überwachen. Z.B. ob es APT Updates gibt, ob ein Dateisystem droht vollzulaufen, ob dein Nextcloud service noch erreichbar ist, ob Nextcloud Apps aktualisierbar sind, ob CPU oder RAM Auslastung Auffälligkeiten zeigen, ob eine Disk langsam am sterben ist, ...
Und da könntest du dich dann rechtzeitg per eMail oder ähnliches warnen lassen.

Wenn du nur schnell wissen willst wann der crash war würde ich im Nextcloud Gast in die /var/log/syslog und /var/log/syslog.1 gucken, nachdem du die gecrashte VM neugeszartet hast. Ab dem Zeitpunkt des Crashs sollten dann bis zum Reboot die Lognachrichten ausbleiben.

 

[mueller]

Danke für die Tipps
Anhand von /var/log/syslog konnte ich feststellen, dass der "Kontakt" um 03:15:01 "abgebrochen" ist und der Neustart um 08:14:40 erfolgt ist

Aug 4 03:15:01 nextcloud-prox qemu-ga: info: guest-fsfreeze called Aug 4 08:14:40 nextcloud-prox systemd[1]: Starting Flush Journal to Persistent Storage...

Um 3:15 beginnt der mit dem backup.
Die journal.txt Datei habe ich erstellt.
Zur Zeit tüfftel ich nach daran, wie ich diese auf einen USB-Stick kopiert bekomme, der wird hier nicht ohne weiteres erkannt

 

[mueller]

... ich habe der Einfachheit halber den "kritischen" Zeitraum kopiert.
Reicht das so?

 

[Dunuin]

Fsfreeze wird ausgeführt wenn der Gast wegen Backup die Caches flushen soll etc. Da wird dann für das Backup temporär die virtuellen Disks "eingefroren" damit man ein integres Backup bekommt. Nach dem Backup sollte ein fsthaw kommen, was aber nicht passiert, also scheint wohl das Backup den Gast zum crashen zu bringen. Wäre also nützlich wenn du auch mal die Logs vom Backup Job zeigen könntest (Unten in PVE bei den Logs auf den Log vom Backup-Job doppelklicken führ ausfühlichere Infos).

 

[mueller]

... ich hoffe, ich habe die richtigen Daten kopiert

 

[Dunuin]

Da stimmt was mit dem fsfreeze nicht:

INFO: issuing guest-agent 'fs-freeze' command
ERROR: VM 104 qmp command 'guest-fsfreeze-freeze' failed - got timeout
INFO: issuing guest-agent 'fs-thaw' command
ERROR: VM 104 qmp command 'guest-fsfreeze-thaw' failed - got timeout

Dein Debian ist 11.4 mit dem aktuellstem "qemu-guest-agent" Package?

Vorübergehend könntest du den QEMU Guest Agent für die VM deaktivieren, dann würde der kein Fsfreeze versuchen zu nutzen. Ist aber auch keine Dauerlösung, da du mit Snapshot-Mode Backups ohne Fsfreeze keine Datenintegrität der Backups hast. Da würde ich dann lieber Stop-Mode Backups machen bs das Problem gelöst ist.

 

[mueller]

Ja, ist alles auf dem neusten Stand.

Wird das Problem auch > HIER < beschrieben?

 

[mueller]

Ich habe jetzt mal den backup-Zyklus von täglich auf wöchentlich geändert.
Das ist zwar nicht das, was ich mir so vorstelle, hilft aber erstmal - kein backup, kein crash.
Mit einem Neustart pro Woche, kann ich leben. Nahezu täglich hat doch etwas genervt.

Wenn das ein bug sein sollte, dann hoffe ich, dass er schnell gefixt wird

 

[ITT]

Wir haben hier ca. 10 Nextcloud-Instanzen (Ubuntu/Debian/LXC) und keinerlei solcher Probleme...

 

[mueller]

Ok, dann frage ich mich, ob hier ein Konfigurationsfehler vorliegt.
Bei PVE und PBS habe ich alles über die GUI konfiguriert - also keine Experimente vorgenommen

Leider habe ich keine Idee an welchen "Schrauben" ich drehen kann.
Hast Du einen Tipp für mich?
Dafür wäre ich dankbar ...

 

[mira]

Könntest du die VM Config posten? qm config <VMID>
Womöglich gibt es eine Möglichkeit den Main Thread, in dem die QMP Commands laufen, zu entlasten, z.B. durch das Verwenden von I/O Threads.

 

[mueller]

Hi,
klar

 

[mueller]

root@pve:~# qm config 104
agent: 1
balloon: 6000
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 4
cpu: host
efidisk0: local-lvm:vm-104-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
ide2: none,media=cdrom
memory: 12000
meta: creation-qemu=6.1.1,ctime=1647795940
name: nextcloud-prox
net0: virtio=EA:C4:D9:66:0A:D1,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: local-lvm:vm-104-disk-1,discard=on,iothread=1,size=920G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=79284ca7-c112-4bc3-89cb-0ecf0849c3f7
sockets: 1
vga: virtio
vmgenid: 6fa8cb28-b461-49ca-a413-747502bd76cb

 

[mira]

Also iothread ist schon gesetzt. Das sorgt immerhin für einen eigenen Thread für I/O von/zu dieser Disk.
Wie verhält sich denn die VM wenn du in der VM ein sync ausführst?

 

[mueller]

Entschuldige, ich beschäftige mich noch nicht allzu lange mit Proxmox
Was meinst Du genau mit "ein sync in der VM ausführen"?
Ein manuelles backup?

 

[mira]

Nein, in der VM in einer Shell den Befehl sync ausführen. Am besten wenn die VM bereits eine Weile läuft.
Dies sorgt dafür, dass alle ausstehenden Writes wirklich auf die Festplatte geschrieben werden.

 

[mueller]

Also, wenn ich mich in der VM auf Debian (Basis für Nextcloud) per ssh einlogge und dort sync eingebe, passiert genau nichts:
root@nextcloud-prox:/home/dirk# sync root@nextcloud-prox:/home/dirk#