Nextcloud Proxmox Absturz

mueller

New Member
Feb 20, 2022
22
0
1
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

Proxmox Staff Member
Staff member
Aug 1, 2018
1,762
192
83
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

New Member
Feb 20, 2022
22
0
1
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

Famous Member
Jun 30, 2020
6,756
1,571
149
Germany
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

New Member
Feb 20, 2022
22
0
1
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

New Member
Feb 20, 2022
22
0
1
... ich habe der Einfachheit halber den "kritischen" Zeitraum kopiert.
Reicht das so?
 

Attachments

  • journal.txt
    5.5 KB · Views: 3

Dunuin

Famous Member
Jun 30, 2020
6,756
1,571
149
Germany
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

New Member
Feb 20, 2022
22
0
1
... ich hoffe, ich habe die richtigen Daten kopiert :)
 

Attachments

  • backup_log.txt
    7.5 KB · Views: 2

Dunuin

Famous Member
Jun 30, 2020
6,756
1,571
149
Germany
Da stimmt was mit dem fsfreeze nicht:
Code:
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.
 
Last edited:

mueller

New Member
Feb 20, 2022
22
0
1
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 :)
 
Last edited:

mueller

New Member
Feb 20, 2022
22
0
1
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

Proxmox Staff Member
Staff member
Aug 1, 2018
1,762
192
83
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

New Member
Feb 20, 2022
22
0
1
Code:
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

Proxmox Staff Member
Staff member
Aug 1, 2018
1,762
192
83
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

New Member
Feb 20, 2022
22
0
1
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?
 
Last edited:

mira

Proxmox Staff Member
Staff member
Aug 1, 2018
1,762
192
83
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

New Member
Feb 20, 2022
22
0
1
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#
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!