Servus,

ich hoffe ich finde hier zumindest eine Idee woran es liegen könnte.... mein Unraid Server 6.9.2 läuft eigentlich super stabil und das monatelang. In den letzten 7 Tagen ist er aber dreimal von jetzt auf gleich einfach abgestürzt, so dass nur ein Reboot über IPMI geholfen hat. Nach dem letzten Absturz (vor vier Tagen habe ich das Syslog auf das Flashdrive sichern lassen und dort sind in den Stunden vor dem Absturz jede Menge merkwürdiger Vorgänge zu sehen die sich auch scheinbar ständig wiederholen bis dann der Absturz folgt. Ich hänge mal das Logfile der letzten Tage an und wäre extrem dankbar für hilfreiche Tips...

Danke euch schon mal fürs Reinschauen!

syslog

1 hour ago, Saeros said:

ich hoffe ich finde hier zumindest eine Idee woran es liegen könnte.... mein Unraid Server 6.9.2 läuft eigentlich super stabil und das monatelang. In den letzten 7 Tagen ist er aber dreimal von jetzt auf gleich einfach abgestürzt, so dass nur ein Reboot über IPMI geholfen hat.

syslog 3.55 MB · 1 download

Also es sieht mir so aus, als wenn das System rund 2 tage problemlos läuft und dann ab Jul 16 22:30:11 teils im 1 Minuten oder sogar 10 Sekundentakt immer wieder ähnliche Fehlermeldungen auswirft. Das sieht mir wie diverse Registerinfos aus.

 

Ich weiß zu wenig von unraid oder Linux um das wirklich zu interpretieren, aber nur so als Anfangsidee/Frage/Schuß ins Blaue:

Hast Du mal memtest 24h durchtesten lassen?

Nicht, daß es ein Hardwareproblem im Speicher ist?

Bis jetzt noch nicht, das könnte ich mal versuchen. Ist schon komisch, dass es so plötzlich auftritt, verändert hat sich nichts, lief vorher monatelang stabil.

...sieht verdächtig nach dem "Bug" aus, der bei einigen auftritt, wenn Docker auf custom.brX und auch VMs da drauf liegen -> mal auf v6.10 gehen.

Hast du container UND VMs im br0 Netzwerk? Dann wird es vermutlich daran liegen. In unRAID 6.10 kann man von macvlan auf ipvlan in den Docker Einstellungen wechseln. Alternativ versuchen br0 nicht zu verwenden.

 

VMs habe ich gar keine, nur Docker. Und die verteilen sich bunt gemischt auf Bridge und Host. Bisher kein eigenes Docker Netzwerk. 

So ein Bug taucht doch auch nicht nach Monaten plötzlich vermehrt auf oder?

3 hours ago, mgutt said:

Hast du container UND VMs im br0 Netzwerk? Dann wird es vermutlich daran liegen.

...ich glaube es reicht wenn man zu Dockern auf custom bridge einfach nur ne VM hat. Ich habe den Bug auch gehabt und meine, einzige VM hat nen NIC physisch durchgereicht.

Seitdem fingen die Call-traces an...

 

Mit 6.10, trotz macvlans ist bisher Ruhe...

 

3 hours ago, Saeros said:

So ein Bug taucht doch auch nicht nach Monaten plötzlich vermehrt auf oder?

...hat vermutlich auch was mit Nutzung/Last zu tun, also kein Konfigurations-Thema allein.

 

Allerdings habe ich keine einzige VM...

Ich würde ja sofort auf 6.10 gehen, allein um es zu testen, aber ich habe Bedenken wegen meiner IPMI Fan Steuerung, da haben schon einige gesagt dass es seit dem Update Probleme gibt bzw. es nicht mehr funktioniert. 

Könnte es noch eine andere Lösung/Ursache geben? 

Auf jeden Fall schon mal Danke dass ihr euch mit meinem Problem beschäftigt!

Da steht was von btrfs in den Kernel Fehler 

 

Jul 17 12:28:11 MEIN_SERVER kernel: #PF: error_code(0x0000) - not-present page
Jul 17 12:28:11 MEIN_SERVER kernel: PGD 8000000142cc2067 P4D 8000000142cc2067 PUD 142cc3067 PMD 0 
Jul 17 12:28:11 MEIN_SERVER kernel: Oops: 0000 [#4] SMP PTI
Jul 17 12:28:11 MEIN_SERVER kernel: CPU: 2 PID: 6045 Comm: emhttpd Tainted: G      D W         5.10.28-Unraid #1
Jul 17 12:28:11 MEIN_SERVER kernel: Hardware name: Supermicro Super Server/X11SCH-LN4F, BIOS 1.5 11/17/2020
Jul 17 12:28:11 MEIN_SERVER kernel: RIP: 0010:btrfs_statfs+0x300/0x4bc
Jul 17 12:28:11 MEIN_SERVER kernel: Code: a1 94 c2 81 41 c1 e3 10 4d 63 db 48 8b 95 98 00 00 00 48 8d 8d 98 00 00 00 31 c0 4d 8d 83 00 00 10 00 48 39 ca 48 63 f0 74 50 <48> 8b 7a 60 40 80 e7 02 74 41 48 83 7a 50 00 74 3a 48 8b 7a 60 40
Jul 17 12:28:11 MEIN_SERVER kernel: RSP: 0018:ffffc900007dbdd0 EFLAGS: 00010213
Jul 17 12:28:11 MEIN_SERVER kernel: RAX: 0000000000000002 RBX: 0000000000000001 RCX: ffff888100f18c98
Jul 17 12:28:11 MEIN_SERVER kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: 000000b75eca0000
Jul 17 12:28:11 MEIN_SERVER kernel: RBP: ffff888100f18c00 R08: 0000000000110000 R09: 0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: R10: 0000000000000002 R11: 0000000000010000 R12: ffff88814b335000
Jul 17 12:28:11 MEIN_SERVER kernel: R13: ffffc900007dbeb8 R14: 0000000000000002 R15: ffff88821596a900
Jul 17 12:28:11 MEIN_SERVER kernel: FS:  0000150dfef74700(0000) GS:ffff88885f280000(0000) knlGS:0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 17 12:28:11 MEIN_SERVER kernel: CR2: 0000000000000060 CR3: 0000000100d20004 CR4: 00000000003706e0
Jul 17 12:28:11 MEIN_SERVER kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jul 17 12:28:11 MEIN_SERVER kernel: Call Trace:
Jul 17 12:28:11 MEIN_SERVER kernel: statfs_by_dentry+0x3b/0x51
Jul 17 12:28:11 MEIN_SERVER kernel: vfs_statfs+0x11/0x91
Jul 17 12:28:11 MEIN_SERVER kernel: user_statfs+0x4f/0x96
Jul 17 12:28:11 MEIN_SERVER kernel: __do_sys_statfs+0x20/0x4c
Jul 17 12:28:11 MEIN_SERVER kernel: do_syscall_64+0x5d/0x6a
Jul 17 12:28:11 MEIN_SERVER kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jul 17 12:28:11 MEIN_SERVER kernel: RIP: 0033:0x150dff8b4267
Jul 17 12:28:11 MEIN_SERVER kernel: Code: 44 00 00 48 8b 05 29 8c 0d 00 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 89 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f9 8b 0d 00 f7 d8 64 89 01 48
Jul 17 12:28:11 MEIN_SERVER kernel: RSP: 002b:0000150dfef73a38 EFLAGS: 00000203 ORIG_RAX: 0000000000000089
Jul 17 12:28:11 MEIN_SERVER kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000150dff8b4267
Jul 17 12:28:11 MEIN_SERVER kernel: RDX: 0000150dfef73b00 RSI: 0000150dfef73a40 RDI: 0000150dfef73bb0
Jul 17 12:28:11 MEIN_SERVER kernel: RBP: 0000150dfef73bb0 R08: 0000150dff98a4e0 R09: 000000000000000a
Jul 17 12:28:11 MEIN_SERVER kernel: R10: 000000000042045a R11: 0000000000000203 R12: 0000150dfef73b00
Jul 17 12:28:11 MEIN_SERVER kernel: R13: 0000150dfef73a40 R14: 0000150dfef73fc0 R15: 0000150dfef74700
Jul 17 12:28:11 MEIN_SERVER kernel: Modules linked in: macvlan tun veth xt_nat xt_tcpudp xt_conntrack nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter xfs nfsd lockd grace sunrpc md_mod i915 iosf_mbi drm_kms_helper drm intel_gtt agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops ipmi_devintf iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libblake2s blake2s_x86_64 libblake2s_generic libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables igb i2c_algo_bit x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd wmi_bmof glue_helper rapl intel_cstate mpt3sas ahci ipmi_ssif intel_uncore video libahci i2c_i801 nvme wmi thermal backlight acpi_ipmi raid_class intel_pch_thermal nvme_core scsi_transport_sas input_leds i2c_smbus i2c_core led_class
Jul 17 12:28:11 MEIN_SERVER kernel: ipmi_si ie31200_edac acpi_power_meter fan acpi_pad button [last unloaded: i2c_algo_bit]
Jul 17 12:28:11 MEIN_SERVER kernel: CR2: 0000000000000060
Jul 17 12:28:11 MEIN_SERVER kernel: ---[ end trace 040dc977f8d2cef1 ]---
Jul 17 12:28:11 MEIN_SERVER kernel: RIP: 0010:nf_ct_tuplehash_to_ctrack+0x0/0xe [nf_conntrack]
Jul 17 12:28:11 MEIN_SERVER kernel: Code: c3 48 8b 07 48 8b 57 08 a8 01 48 89 02 75 04 48 89 50 08 c3 48 8b 06 48 89 77 08 48 89 07 a8 01 48 89 3e 75 04 48 89 78 08 c3 <0f> b6 47 37 48 6b c0 c8 48 8d 44 07 f0 c3 48 8b 87 b8 00 00 00 48
Jul 17 12:28:11 MEIN_SERVER kernel: RSP: 0018:ffffc90002ea7e40 EFLAGS: 00010206
Jul 17 12:28:11 MEIN_SERVER kernel: RAX: 00000000120f6fbc RBX: 0000000000000000 RCX: ffff88813a100000
Jul 17 12:28:11 MEIN_SERVER kernel: RDX: 000000010ce913bc RSI: ffffc90002ea7e5c RDI: 0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: RBP: 000000000000b6f6 R08: 0000000000000000 R09: 0000746e65696369
Jul 17 12:28:11 MEIN_SERVER kernel: R10: 8080808080808080 R11: fefefefefefefeff R12: ffffffffa01c15a0
Jul 17 12:28:11 MEIN_SERVER kernel: R13: 0000000000000009 R14: 0000000000000000 R15: ffff88814cc965f0
Jul 17 12:28:11 MEIN_SERVER kernel: FS:  0000150dfef74700(0000) GS:ffff88885f280000(0000) knlGS:0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 17 12:28:11 MEIN_SERVER kernel: CR2: 0000000000000060 CR3: 0000000100d20004 CR4: 00000000003706e0
Jul 17 12:28:11 MEIN_SERVER kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jul 17 12:28:11 MEIN_SERVER kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Ich würde daher erstmal alle btrfs volumes reparieren.

Das wären dann die gespiegelten NVME Cache Drives... reicht da die Scrub Funktion (mit gesetztem Repair-Haken) oder wie stosse ich die Reparatur am besten an?

Ah, ich hatte nur die conntrack Call-Traces gesehen...

 

Aber: ...das Problem hatte ich vor ein paar Monaten auch regelmässig, imer häufiger....BTRFS Pool (Cache) bleibt mit btrfs Fehler (im docker img/loop2) einfach stehen.

Nach Neustart keine BTRFS Fehler vorhanden ;-(

Ich hatte dann nochmal Lüfter für die NVMe nachgerüstet, ohne Erfolg...ebenso von NVME auf SATA-SSD getauscht...ohne Erfolg...seit 15 Tagen bin ich jetzt auf 6.10.3 mit den SSD und beobachte.

 

...auf Docker-Verzeichnisse kann ich aus bestimmten Gründen nicht so leicht wechseln....daher ml der Versuch mit 6.10.3  bei mir.

 

 

Das Einzige was mir auch noch aufgefallen ist, es läuft immer ein Prozess der sich dauerhaft zwischen 22 und 30% krallt (meistens läuft er auf 29%): 

 

root 5888 22.7 0.0 0 0 ? S Jul17 569:52 [unraidd0]

 

Angeblich hat der mit Parity Check zu tun, aber der ist schon lange abgeschlossen.

19 hours ago, Saeros said:

reicht da die Scrub Funktion

Ja. Scrub berechnet alle Prüfsummen neu und gibt evtl Datenfehler aus.

 

Zwischenstand: Ich habe noch immer keine Ahnung, aber immerhin seit Sonntag kein weiterer Absturz...