Grommunio Server reagiert nicht mehr nach ca 3 Tagen Laufzeit

msr · 2024-07-29T08:02:04+00:00

Moin, mein Server reagiert nicht mehr seit dem Update Mitte Juli nach ca 3 Tagen Laufzeit. Kein Zugang mehr über SSH oder Webinterface mehr möglich. Emails w...

crpb

un die?

dbus-uuidgen --ensure
dbus-uuidgen --ensure=/etc/machine-id
# und dann gefolgt von
systemd-machine-id-setup
systemd-machine-id-setup --commit

ich find meine notiz dazu nicht und habs auch schon ne weile nicht mehr gemacht deswegen bin ich auch nicht mehr sicher welche reihenfolge es war ~_~

msr

crpb un die?

geht ohne Fehlermeldung.
Nach 2 mal reboot sieht das schon besser aus:
journalctl --list-boots -2 495946b48841476788f826b23cc433ac Wed 2022-10-19 12:13:52 CEST—Wed 2022-10-19 12:17:40 CEST -1 1c17c26b43094234810ab5479185faa7 Mon 2024-07-29 13:07:26 CEST—Mon 2024-07-29 13:09:04 CEST 0 92bc99baa8ed40148e7257b06869a816 Mon 2024-07-29 13:09:19 CEST—Mon 2024-07-29 13:10:21 CEST

crpb

Ah super, dann würde ich jetzt einfach mal sagen laufen lassen und wieder kommen wenn wir auch was nachschauen können.

msr

crpb Ah super, dann würde ich jetzt einfach mal sagen laufen lassen und wieder kommen wenn wir auch was nachschauen können.

jupp, werde dann feedback geben, danke

msr

so jetzt war es wieder soweit, ausgefallen muss er heute 30.07. so gegen 17.00Uhr sein. Was im Log steht ist von gestern kurz nach dem Neustart.
:~ # journalctl -b -1 -p 4 Jul 29 13:09:19 srv-xxx kernel: #2 Jul 29 13:09:19 srv-xxx kernel: #3 Jul 29 13:09:19 srv-xxx kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. Jul 29 13:09:19 srv-xxx kernel: sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking Jul 29 13:09:23 srv-xxx kernel: sd 0:0:0:0: Power-on or device reset occurred Jul 29 13:09:23 srv-xxx systemd[1]: Configuration file /usr/lib/systemd/system/searchd.service is marked world-inaccessible. This has no effect as configuration data is> Jul 29 13:09:24 srv-xxx kernel: FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. Jul 29 13:10:01 srv-xxx sshd[2171]: error: kex_exchange_identification: Connection closed by remote host Jul 29 13:10:04 srv-xxx systemd[1]: rabbitmq-server.service: Supervising process 1544 which is not our child. We'll most likely not notice when it exits. Jul 30 01:13:30 srv-xxx kernel: hrtimer: interrupt took 5567811 ns

@crbp soll ich jetzt folgenden command ausführen oder was schlägst Du vor?
btrfs check --repair /dev/sda2

sda2 ist boot/efi

crpb

Ne, FAT-fs (sda2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. das ist die boot-partition /boot/efi

Kannste mittels fsck /dev/sda2 mal laufen lassen aber das ist nicht das problem.

Sieht etwa so aus

gromi:~ # fsck /dev/sda2
fsck from util-linux 2.37.4
fsck.fat 4.1 (2017-01-24)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n) y
/dev/sda2: 22 files, 4864/10211 clusters

Evtl. kommt was von wegen kopiere von backup auf blah.. einfach bestätigen.. noch mal laufen lassen und dann ist das erstmal wieder 'sauber'..

Aber warum die Kiste einfach hängt...
Läuft nen backup-job der kein fleecing hat oder so und somit zu überlastet beim "suspend"?

msr

crpb Läuft nen backup-job der kein fleecing hat oder so und somit zu überlastet beim "suspend"?

ja heute lief zu der Zeit ein Backup Job ohne fleecing. Nur der läuft schon seit langer Zeit.

Ich werde mal fleecing aktivieren und dann weiter beobachten.

eryx

Ich hab das unregelmäßiger. Bei mir ist das dann meist der rspamd der in nen loop gerät und irgendwann regliche IO's bansprucht, so dass der server langsam wegstirbt. Hab aber noch nicht rausbekommen woran das liegt. Dann geht auch nur ein harter Reboot, dann läuft aber wieder alles.

crpb

Hmm teil der nachricht war fott..

Also ich konnte sowas mit rspamd noch nirgends sehen aber ich hab auch kein system was direkt mit dem netz kommuniziert... naja übermorgen dann aber sonst ist alles hinter mailrelays was vielleicht nen unterschied macht.

msr

crpb
Bei mir ist auch alles hinter einem proxmox mail gateway und einem Reverse Proxy.

Habe mir heute mal das Monitoring der letzten 3 Wochen genauer angeschaut. Keine Storage I/O oder Load Probleme vorhanden. Nur Netzwerktraffic Peak von 12 MB beim Backup.

Warten wir halt mal ab ob fleecing neue Erkenntnisse bring

crpb

Jo, ich bin noch ganz taufrisch mit proxmox aber fleecing habe ich in den ersten tests schnell bemerkt das es doch ganz praktisch ist. Natürlich nur mit lokalem schnellen speicher ;--)

msr

crpb
Hab das fleecing auf lokale ZFS RAID1 250G SSD‘s konfiguriert. Gucke mir das heute Abend beim Backup mal an. Hab keinen Plan was das für Speicherplatz braucht. Könnte auch alternativ ZFS RAID10 SSD oder ZFS RAID1 SSD auf NVMe testen.

crpb

Das ist nur temp. während des backupjobs und wird dann auch direkt wieder gedroppt.

Ich habe ne 16GB lvmthin auf nem host und da macht auch ne vm mit 350gb disk kein problem.

Sind ja nur die schreibvorgänge während des backups wenn ich es richtig verstanden habe.
https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_vm_backup_fleecing

Und is auch nur lvm weil das ZFS von ner TrueNAS kommt und nicht mit lokalen platten versorgt wird. Sollte halt THIN sein für kleinen verbrauch!

msr

bislang gab es keine Probleme mehr.
fleecing in den Backups scheint das Problem behoben zu haben.
Frage mich nur warum nur bei einer VM von 19 das Problem und erst nach dem Update Anfang Juni auftrat.
Die Backups vom PBS laufen schon ewig.
Allerdings haben der proxmox PBS und PVE da auch ein Update erhalten.