[SOLVED] Ceph OSD: "Kernel NULL Pointer dereference"

[Ingo S]

Moin zusammen

Ich mache jetzt hier mal einen Thread auf, weil es schon der zweite Server ist, auf dem eine OSD "abgestürzt" ist mit der gleichen Kernel Fehlermeldung.

Spoiler: Kernel LOG

[Dec24 02:28] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  +0.000039] #PF: supervisor instruction fetch in kernel mode
[  +0.000036] #PF: error_code(0x0010) - not-present page
[  +0.000017] PGD 8000001094911067 P4D 8000001094911067 PUD 1094912067 PMD 0
[  +0.000024] Oops: 0010 [#1] SMP PTI
[  +0.000013] CPU: 34 PID: 290278 Comm: ngs-pulsar Tainted: P           O      5.11.22-4-pve #1
[  +0.000027] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
[  +0.000020] RIP: 0010:0x0
[  +0.000013] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[  +0.000021] RSP: 0018:ffffa4648c6efb00 EFLAGS: 00010246
[  +0.000017] RAX: 0000000000000000 RBX: ffffa4648c6efb88 RCX: 0000000000000002
[  +0.000022] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88e1c4b1f400
[  +0.000021] RBP: ffffa4648c6efb08 R08: 0000000000000000 R09: 0000000000000015
[  +0.000021] R10: 0000000000000655 R11: 000000000000000a R12: ffff88e1c4b1f400
[  +0.000021] R13: ffff88e1ce2d6400 R14: 0000000000000000 R15: 0000000000000001
[  +0.000022] FS:  00007fab40d0ff38(0000) GS:ffff88e17fd80000(0000) knlGS:0000000000000000
[  +0.000042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000019] CR2: ffffffffffffffd6 CR3: 00000019f329e004 CR4: 00000000003726e0
[  +0.000039] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000022] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  +0.000023] Call Trace:
[  +0.000012]  blk_mq_put_rq_ref+0x47/0x60
[  +0.000021]  bt_iter+0x54/0x90
[  +0.000013]  blk_mq_queue_tag_busy_iter+0x1a2/0x2d0
[  +0.000018]  ? blk_add_rq_to_plug+0x50/0x50
[  +0.000017]  ? blk_add_rq_to_plug+0x50/0x50
[  +0.000018]  blk_mq_in_flight+0x38/0x60
[  +0.000016]  diskstats_show+0x159/0x300
[  +0.000017]  seq_read_iter+0x2c6/0x4b0
[  +0.000016]  proc_reg_read_iter+0x51/0x80
[  +0.000017]  new_sync_read+0x10d/0x190
[  +0.000018]  vfs_read+0x15a/0x1c0
[  +0.000014]  ksys_read+0x67/0xe0
[  +0.000014]  __x64_sys_read+0x1a/0x20
[  +0.000032]  do_syscall_64+0x38/0x90
[  +0.000015]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  +0.000035] RIP: 0033:0x47dd7b
[  +0.000012] Code: e8 2a 98 fe ff eb 88 cc cc cc cc cc cc cc cc e8 bb dd fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7>
[  +0.000049] RSP: 002b:000000c00226b4e8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000
[  +0.000022] RAX: ffffffffffffffda RBX: 000000c00004a000 RCX: 000000000047dd7b
[  +0.000022] RDX: 0000000000001000 RSI: 000000c001c63000 RDI: 000000000000006d
[  +0.000021] RBP: 000000c00226b538 R08: 0000000000000001 R09: 000000c001e7c840
[  +0.000021] R10: 000000c0006ea0b8 R11: 0000000000000212 R12: 000000c00226b728
[  +0.000021] R13: 0000000000000000 R14: 000000c00050e4e0 R15: ffffffffffffffff
[  +0.000022] Modules linked in: nfnetlink_queue nft_queue nf_tables tcp_diag inet_diag veth rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs lockd grace nfs_ssc fscache ebta>
[  +0.000083]  libiscsi_tcp libiscsi scsi_transport_iscsi drm sunrpc ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison >
[  +0.000404] CR2: 0000000000000000
[  +0.000014] ---[ end trace 7095f43d1d4ee59d ]---
[  +1.418120] RIP: 0010:0x0
[  +0.000026] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[  +0.000041] RSP: 0018:ffffa4648c6efb00 EFLAGS: 00010246
[  +0.002345] RAX: 0000000000000000 RBX: ffffa4648c6efb88 RCX: 0000000000000002
[  +0.002404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88e1c4b1f400
[  +0.001598] RBP: ffffa4648c6efb08 R08: 0000000000000000 R09: 0000000000000015
[  +0.001266] R10: 0000000000000655 R11: 000000000000000a R12: ffff88e1c4b1f400
[  +0.001279] R13: ffff88e1ce2d6400 R14: 0000000000000000 R15: 0000000000000001
[  +0.001805] FS:  00007fab40d0ff38(0000) GS:ffff88e17fd80000(0000) knlGS:0000000000000000
[  +0.002303] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.002240] CR2: ffffffffffffffd6 CR3: 00000019f329e004 CR4: 00000000003726e0
[  +0.002223] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.002207] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Bei beiden Vorfällen, habe ich ein NULL Pointer derefence im Kernel Log gefunden. Wenn das passiert ist eine OSD down und out und ceph-osd.x lässt sich nicht mehr starten.
Das Device ist noch vorhanden, es gibt keine Hinweise auf read oder write error und drauf schreiben und lesen kann ich auch.

Der Prozess für osd.x ist jetzt ein Zombie, weshalb ich die OSD dann auch nicht wieder hoch fahren kann. Leider ist PID 1 parent des OSD Prozesses, so das ich auch den parent nicht killen kann.
Ich kann leider den Server auch nicht einfach neu starten, da wir zur Zeit aufm Cluster etwas zu knapp mit dem RAM sind (Aufrüstung ist gleich Anfang nächsten Jahres, da haben wir neues Budget)
Was tun?

Achso, bevor ich es vergesse:
Hier die Versionen:

Spoiler: root@vm-2:~# pveversion --verbose

proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-helper: 7.1-2
pve-kernel-5.11: 7.0-7
pve-kernel-5.4: 6.4-5
pve-kernel-5.11.22-4-pve: 5.11.22-8
pve-kernel-5.4.128-1-pve: 5.4.128-2
ceph: 16.2.6-pve2
ceph-fuse: 16.2.6-pve2
corosync: 3.1.5-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-9
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-11
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-10
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-3
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.5-1
pve-qemu-kvm: 6.0.0-4
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-14
smartmontools: 7.2-pve2
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1

 

[Stoiko Ivanov]

der trace deutet auf ein Problem im blockdevice layer hin - kann die disk sein, kann ein kabel sein, kann aber auch ein software problem sein

allerdings gibt es schon eine reihe neuerer Kernel (und auch sonstiger Pakete) - pve-kernel-5.13 , mittlerweile auch pve-kernel-5.15

ich würde vorschlagen mal alles auf neuesten Stand zu bringen und auch mit einem neueren Kernel zu versuchen

(klarerweise sicherstellen, dass Ihr ein funktionierendes Backup habt bevor Ihr loslegt)

Auch würde ich mal schauen ob es ein BIOS-upgrade für das System gibt (2015 ist doch schon etwas alt)

Ich hoffe das hilft!

 

[Ingo S]

Vielen Dank erstmal

Ich werde mal prüfen, was ich da machen kann.
Interessant ist halt, dass dieser Fehler jetzt bei zwei verschiedenen Servern, im Abstand von etwa einer Woche, aufgetreten ist. Die Disk scheint aber in Ordnung zu sein.
Updaten ist zur Zeit ein wenig schwierig, da wir wie gesagt etwas zu knapp mit dem RAM sind.

Im Januar wollen wir den Cluster modernisieren. Da würde sich das mit dem BIOS etc. sowieso alles erledigen. Ich werde das jetzt genau beobachten und mal schauen ob ich ein Zeitfenster für einen Reboot finde, da ich dafür die VMs auf dem Server herunterfahren müsste.
Ich mache mir nur etwas Sorgen, dass das ein Software Problem sein könnte, das uns nach und nach um die Ohren fliegt.
hmm...

 

[Ingo S]

So, also einen Hardware defekt kann ich ziemlich ausschließen. Wir hatten diesen Fehler jetzt bei drei verschiedenen Servern. Ich kann mir nicht vorstellen, dass der Servercluster Jahrelang läuft und dann irgendwann tauchen auf drei verschiedenen Servern die gleichen Fehlermeldungen auf.

Direkt an Silvester ist uns auch wieder ein Server mit dieser Fehlermeldung komplett abgerauscht.

Spoiler: Kernel LOG

[Jan 3 06:14] BUG: kernel NULL pointer dereference, address: 00000000000000c0
[ +0.000040] #PF: supervisor read access in kernel mode
[ +0.000019] #PF: error_code(0x0000) - not-present page
[ +0.000019] PGD 800000013f9ed067 P4D 800000013f9ed067 PUD 13f9ee067 PMD 0
[ +0.000027] Oops: 0000 [#1] SMP PTI
[ +0.000016] CPU: 28 PID: 1960 Comm: ngs-pulsar Tainted: P O 5.11.22-4-pve #1
[ +0.000043] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
[ +0.000022] RIP: 0010:blk_mq_put_rq_ref+0xa/0x60
[ +0.000038] Code: 15 0f b6 d3 4c 89 e7 be 01 00 00 00 e8 cf fe ff ff 5b 41 5c 5d c3 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 10 <48> 8b 80 c0 00 00 00 48 89 e5 48 3b 78 40 74 1f 4c 8d 87 e8 00 00
[ +0.000052] RSP: 0018:ffffb733c80bfb08 EFLAGS: 00010206
[ +0.000036] RAX: 0000000000000000 RBX: ffffb733c80bfb88 RCX: 0000000000000002
[ +0.000023] RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffff97f14d9ad000
[ +0.000023] RBP: ffffb733c80bfb40 R08: 0000000000000000 R09: 0000000000000033
[ +0.000024] R10: 00000000000007cf R11: 000000000000000e R12: ffff97f14d9ad000
[ +0.000036] R13: ffff97f14df52000 R14: 0000000000000000 R15: 0000000000000001
[ +0.000021] FS: 00007f9a732e1f38(0000) GS:ffff97f0ffc00000(0000) knlGS:0000000000000000
[ +0.000023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000017] CR2: 00000000000000c0 CR3: 0000000146402003 CR4: 00000000003726e0
[ +0.000021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.000021] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ +0.000020] Call Trace:
[ +0.000011] ? bt_iter+0x54/0x90
[ +0.000013] blk_mq_queue_tag_busy_iter+0x1a2/0x2d0
[ +0.000017] ? blk_add_rq_to_plug+0x50/0x50
[ +0.000016] ? blk_add_rq_to_plug+0x50/0x50
[ +0.000015] blk_mq_in_flight+0x38/0x60
[ +0.000015] diskstats_show+0x159/0x300
[ +0.000015] seq_read_iter+0x2c6/0x4b0
[ +0.000015] proc_reg_read_iter+0x51/0x80
[ +0.000015] new_sync_read+0x10d/0x190
[ +0.000016] vfs_read+0x15a/0x1c0
[ +0.000013] ksys_read+0x67/0xe0
[ +0.000013] __x64_sys_read+0x1a/0x20
[ +0.000014] do_syscall_64+0x38/0x90
[ +0.000014] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ +0.000019] RIP: 0033:0x47dd7b
[ +0.000012] Code: e8 2a 98 fe ff eb 88 cc cc cc cc cc cc cc cc e8 bb dd fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
[ +0.000049] RSP: 002b:000000c002bdc4e8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000
[ +0.000057] RAX: ffffffffffffffda RBX: 000000c000045000 RCX: 000000000047dd7b
[ +0.000041] RDX: 0000000000001000 RSI: 000000c00215e000 RDI: 0000000000000009
[ +0.000024] RBP: 000000c002bdc538 R08: 0000000000000001 R09: 000000c001899080
[ +0.000023] R10: 000000c0004d0010 R11: 0000000000000212 R12: 000000c002bdc728
[ +0.000023] R13: 0000000000000000 R14: 000000c00050a680 R15: 0000000000000000
[ +0.000025] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfnetlink_queue nft_queue nfsv4 nf_tables nfsv3 nfs_acl nfs lockd grace nfs_ssc veth fscache ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6_tables sctp ip6_udp_tunnel udp_tunnel iptable_filter bpfilter bonding tls softdog nfnetlink_log nfnetlink intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp ast kvm_intel drm_vram_helper drm_ttm_helper kvm ttm drm_kms_helper ipmi_ssif irqbypass cec crct10dif_pclmul ghash_clmulni_intel aesni_intel rc_core fb_sys_fops syscopyarea sysfillrect sysimgblt crypto_simd mei_me cryptd mei joydev input_leds glue_helper rapl intel_cstate ioatdma pcspkr acpi_ipmi efi_pstore ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mxm_wmi acpi_power_meter mac_hid zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) vhost_net vhost vhost_iotlb tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi
[ +0.000070] scsi_transport_iscsi drm sunrpc ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c hid_generic usbmouse usbkbd usbhid hid crc32_pclmul megaraid_sas xhci_pci xhci_pci_renesas i2c_i801 ixgbe lpc_ich nvme i2c_smbus igb ahci ehci_pci xhci_hcd ehci_hcd libahci xfrm_algo i2c_algo_bit nvme_core dca mdio wmi
[ +0.000369] CR2: 00000000000000c0
[ +0.000014] ---[ end trace 17bc75ec71f3b2ec ]---
[ +0.072115] RIP: 0010:blk_mq_put_rq_ref+0xa/0x60
[ +0.000029] Code: 15 0f b6 d3 4c 89 e7 be 01 00 00 00 e8 cf fe ff ff 5b 41 5c 5d c3 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 10 <48> 8b 80 c0 00 00 00 48 89 e5 48 3b 78 40 74 1f 4c 8d 87 e8 00 00
[ +0.000056] RSP: 0018:ffffb733c80bfb08 EFLAGS: 00010206
[ +0.000020] RAX: 0000000000000000 RBX: ffffb733c80bfb88 RCX: 0000000000000002
[ +0.001348] RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffff97f14d9ad000
[ +0.001484] RBP: ffffb733c80bfb40 R08: 0000000000000000 R09: 0000000000000033
[ +0.001418] R10: 00000000000007cf R11: 000000000000000e R12: ffff97f14d9ad000
[ +0.001360] R13: ffff97f14df52000 R14: 0000000000000000 R15: 0000000000000001
[ +0.001341] FS: 00007f9a732e1f38(0000) GS:ffff97f0ffc00000(0000) knlGS:0000000000000000
[ +0.001419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.001401] CR2: 00000000000000c0 CR3: 0000000146402003 CR4: 00000000003726e0
[ +0.001399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.001457] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

 

[Ingo S]

Achso, als weitere Info noch:
Wenn eine OSD auf diese Art abschmiert, dann sieht das so aus:

Im Proxmox WebGUI sieht das so aus:

---

Wenn ich den Dienst dann stoppe und wieder starte passiert das:

 

[Stoiko Ivanov]

So, also einen Hardware defekt kann ich ziemlich ausschließen. Wir hatten diesen Fehler jetzt bei drei verschiedenen Servern. Ich kann mir nicht vorstellen, dass der Servercluster Jahrelang läuft und dann irgendwann tauchen auf drei verschiedenen Servern die gleichen Fehlermeldungen auf.

dann würde sich die frage stellen, wann sich zuletzt was an den Systemen im Cluster verändert hat - z.b. wann wurde das letzte mal der kernel aktualisiert - wann das letzte mal ceph - steht das in einem zeitlichen Zusammenhang?

(wenn es potentiell der kernel ist kann ja mit einer alten version gebootet werden)

Ein allgemeines Problem (dass bei mehreren Usern auftritt) mit diesem Symptomen wäre mir bisher nicht bekannt (heißt klarerweise nicht, dass das nicht geben kann)

 

[Ingo S]

Ich habe da so einen leisen Verdacht, den ich im Moment abkläre. Wenn bisher sonst nichts in dieser Richtung aufgefallen sein sollte, bestärkt das sogar meinen Verdacht, das es eine andere Software Komponente sein könnte. Das lasse ich gerade prüfen.

 

[Ingo S]

So, Update:
Mein Verdacht hat sich bestätigt, wenn auch anders als zunächst vermutet.

Folgendes:
Wir nutzen zur Überwachung von Sicherheitslücken, und Update- und Securitycompliance-Management einen Software-Agent. Dieser triggert einen Kernel-Bug bei Kernelversion < 5.11.22-9, weil er über einen bestimmten Systemaufruf auch Dateisystemstatistiken erfasst.

Siehe: https://lkml.org/lkml/2021/9/10/297
und:
https://forum.proxmox.com/threads/p...code-0x0000-no-web-access-no-ssh.96598/page-2

Mit dem kürzlich veröffentlichten Kernel 5.13 sollte das Problem also behoben sein. Allerdings habe ich heute das Update auf einem der am meisten betroffenen Server gemacht und habe jetzt ein anderes großes Problem:
Nach dem Reboot fällt ca alle Minute das Netzwerk für etwa 5sek einfach weg. Komplett, auf allen Schnittstellen. Der Switch zeigt link, aber der Host ist während der Zeit nicht erreichbar. Es gibt KEINE Meldungen dazu vom Kernel, und im Journal lediglich die Meldungen der Dienste wie Corosync oder Ceph etc, das kein Quorum mehr besteht weil die anderen Hosts nicht erreichbar sind.

Ideen? Habe bereits auch mal den alten Kernel gebootet, gleiches Problem. Der ganze Host ist jetzt offline, da das ständige On-Off den gesamten Cluster lähmt. Alle VMs haben dann IO Probleme, hohe IO Latenz etc.

Habe den Server deshalb bis zur Klärung offline genommen, brauche da aber dringend eine Lösung, da der Cluster jetzt 100% voll ist, was RAM/VM-Anzahl betrifft. ich hoffe, das so lange kein anderer Node ausfällt.

Wie kann ich das debuggen, wenn mir dmesg und journalctl keine Anhaltspunkte geben?

 

[Stoiko Ivanov]

Hmm - ok - ist jetzt ein wenig gemischter erfolg :/

Nach dem Reboot fällt ca alle Minute das Netzwerk für etwa 5sek einfach weg.

Nur damit keine Missverständnisse aufkommen was genau heißt weg?
- ping von dem system zu einem anderen im selben netz geht nicht?
- ping über das default gateway hinaus (z.b. 8.8.8.8) geht nicht?
- dns Auflösung geht nicht wird aber benötigt?
- ping zu dem System geht nicht?
- tcp connection bricht ab?

Ideen? Habe bereits auch mal den alten Kernel gebootet, gleiches Problem.

sprich - nach einmaligem booten von einem 5.13 kernel ist das jetzt auch beim alten (vorher funktionierenden) kernel aufgetreten?!
hätte ich noch nie gesehen und würde zuerst mal überlegen woran das sonst noch so liegen könnte - wurde zum Zeitpunkt des Kernel-upgrades sonst noch irgendetwas gemacht? (kann auch nicht so aussehen als wäre es im Zusammenhang damit stehend)?

Wie kann ich das debuggen, wenn mir dmesg und journalctl keine Anhaltspunkte geben?

potentiell mal das gesamte journal eines boots (bis der Fehler 1-2 mal auftritt) posten - vielleicht sehen wir hier ja noch was

last but not least - vl. auch noch den 5.15 kernel testen?

Hoffe das hilft!

 

[Ingo S]

Ja, echt nicht das Traumergebnis.

Nur damit keine Missverständnisse aufkommen was genau heißt weg?
- ping von dem system zu einem anderen im selben netz geht nicht?
- ping über das default gateway hinaus (z.b. 8.8.8.8) geht nicht?
- dns Auflösung geht nicht wird aber benötigt?
- ping zu dem System geht nicht?
- tcp connection bricht ab?

Netzwerk weg bedeutet kein Ping, kein Corosync, kein Ceph, keine Erreichbarkeit whatsoever, auch im selben Netz, ohne Gateway nur mit IP Adressen.
Bestehende SSH Sitzungen hängen fest bis der Server wieder erreichbar ist, laufen aber dann normal weiter. Ich denke daher, TCP Sitzungen werden nicht zurückgesetzt, sondern können einfach ne Weile nicht kommunizieren.

sprich - nach einmaligem booten von einem 5.13 kernel ist das jetzt auch beim alten (vorher funktionierenden) kernel aufgetreten?!
hätte ich noch nie gesehen und würde zuerst mal überlegen woran das sonst noch so liegen könnte - wurde zum Zeitpunkt des Kernel-upgrades sonst noch irgendetwas gemacht? (kann auch nicht so aussehen als wäre es im Zusammenhang damit stehend)?

Also ich glaube auch nicht, dass es direkt am Kernel liegt. Ich habe ein pveupgrade über die WebGUI gemacht, nicht nur den Kernel. Dabei wurden ja noch ein paar andere Dinge aktualisiert. Ansonsten wurde nichts geändert, also so wirklich gar nichts. Die Maschine lief ja einwandfrei bis zu den Problemem mit dem Kernel Bug. Habe alle VMs von der Maschine weg migriert, das Update angeworfen und neu gestartet.

potentiell mal das gesamte journal eines boots (bis der Fehler 1-2 mal auftritt) posten - vielleicht sehen wir hier ja noch was

Habe das journal komplett hier angehängt.
Zur weiteren Info: Meldungen von "pulsar-m8" sind Meldungen des Agents für die Überwachung, weil die Verbindung zum Server abgebrochen ist.

 

[Ingo S]

Achso, eine Ergänzung noch:
Ich bekomme jetzt plötzlich folgende Fehlermeldung in der WebGUI beim Zugriff auf den abtrünnigen Server:

 

[Ingo S]

Update: Das "invalid PVE ticket" hat sich erledigt. Aus irgendeinem Grund hat sich der Device-Name des Netzwerkadapters für Corosync geändert.

Die Verbindungsprobleme bestehen aber immer noch

 

[ITT]

So, also einen Hardware defekt kann ich ziemlich ausschließen. Wir hatten diesen Fehler jetzt bei drei verschiedenen Servern. Ich kann mir nicht vorstellen, dass der Servercluster Jahrelang läuft und dann irgendwann tauchen auf drei verschiedenen Servern die gleichen Fehlermeldungen auf.

Direkt an Silvester ist uns auch wieder ein Server mit dieser Fehlermeldung komplett abgerauscht.

Spoiler: Kernel LOG

[Jan 3 06:14] BUG: kernel NULL pointer dereference, address: 00000000000000c0
[ +0.000040] #PF: supervisor read access in kernel mode
[ +0.000019] #PF: error_code(0x0000) - not-present page
[ +0.000019] PGD 800000013f9ed067 P4D 800000013f9ed067 PUD 13f9ee067 PMD 0
[ +0.000027] Oops: 0000 [#1] SMP PTI
[ +0.000016] CPU: 28 PID: 1960 Comm: ngs-pulsar Tainted: P O 5.11.22-4-pve #1
[ +0.000043] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
[ +0.000022] RIP: 0010:blk_mq_put_rq_ref+0xa/0x60
[ +0.000038] Code: 15 0f b6 d3 4c 89 e7 be 01 00 00 00 e8 cf fe ff ff 5b 41 5c 5d c3 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 10 <48> 8b 80 c0 00 00 00 48 89 e5 48 3b 78 40 74 1f 4c 8d 87 e8 00 00
[ +0.000052] RSP: 0018:ffffb733c80bfb08 EFLAGS: 00010206
[ +0.000036] RAX: 0000000000000000 RBX: ffffb733c80bfb88 RCX: 0000000000000002
[ +0.000023] RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffff97f14d9ad000
[ +0.000023] RBP: ffffb733c80bfb40 R08: 0000000000000000 R09: 0000000000000033
[ +0.000024] R10: 00000000000007cf R11: 000000000000000e R12: ffff97f14d9ad000
[ +0.000036] R13: ffff97f14df52000 R14: 0000000000000000 R15: 0000000000000001
[ +0.000021] FS: 00007f9a732e1f38(0000) GS:ffff97f0ffc00000(0000) knlGS:0000000000000000
[ +0.000023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000017] CR2: 00000000000000c0 CR3: 0000000146402003 CR4: 00000000003726e0
[ +0.000021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.000021] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ +0.000020] Call Trace:
[ +0.000011] ? bt_iter+0x54/0x90
[ +0.000013] blk_mq_queue_tag_busy_iter+0x1a2/0x2d0
[ +0.000017] ? blk_add_rq_to_plug+0x50/0x50
[ +0.000016] ? blk_add_rq_to_plug+0x50/0x50
[ +0.000015] blk_mq_in_flight+0x38/0x60
[ +0.000015] diskstats_show+0x159/0x300
[ +0.000015] seq_read_iter+0x2c6/0x4b0
[ +0.000015] proc_reg_read_iter+0x51/0x80
[ +0.000015] new_sync_read+0x10d/0x190
[ +0.000016] vfs_read+0x15a/0x1c0
[ +0.000013] ksys_read+0x67/0xe0
[ +0.000013] __x64_sys_read+0x1a/0x20
[ +0.000014] do_syscall_64+0x38/0x90
[ +0.000014] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ +0.000019] RIP: 0033:0x47dd7b
[ +0.000012] Code: e8 2a 98 fe ff eb 88 cc cc cc cc cc cc cc cc e8 bb dd fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
[ +0.000049] RSP: 002b:000000c002bdc4e8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000
[ +0.000057] RAX: ffffffffffffffda RBX: 000000c000045000 RCX: 000000000047dd7b
[ +0.000041] RDX: 0000000000001000 RSI: 000000c00215e000 RDI: 0000000000000009
[ +0.000024] RBP: 000000c002bdc538 R08: 0000000000000001 R09: 000000c001899080
[ +0.000023] R10: 000000c0004d0010 R11: 0000000000000212 R12: 000000c002bdc728
[ +0.000023] R13: 0000000000000000 R14: 000000c00050a680 R15: 0000000000000000
[ +0.000025] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfnetlink_queue nft_queue nfsv4 nf_tables nfsv3 nfs_acl nfs lockd grace nfs_ssc veth fscache ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6_tables sctp ip6_udp_tunnel udp_tunnel iptable_filter bpfilter bonding tls softdog nfnetlink_log nfnetlink intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp ast kvm_intel drm_vram_helper drm_ttm_helper kvm ttm drm_kms_helper ipmi_ssif irqbypass cec crct10dif_pclmul ghash_clmulni_intel aesni_intel rc_core fb_sys_fops syscopyarea sysfillrect sysimgblt crypto_simd mei_me cryptd mei joydev input_leds glue_helper rapl intel_cstate ioatdma pcspkr acpi_ipmi efi_pstore ipmi_si ipmi_devintf ipmi_msghandler acpi_pad mxm_wmi acpi_power_meter mac_hid zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) vhost_net vhost vhost_iotlb tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi
[ +0.000070] scsi_transport_iscsi drm sunrpc ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c hid_generic usbmouse usbkbd usbhid hid crc32_pclmul megaraid_sas xhci_pci xhci_pci_renesas i2c_i801 ixgbe lpc_ich nvme i2c_smbus igb ahci ehci_pci xhci_hcd ehci_hcd libahci xfrm_algo i2c_algo_bit nvme_core dca mdio wmi
[ +0.000369] CR2: 00000000000000c0
[ +0.000014] ---[ end trace 17bc75ec71f3b2ec ]---
[ +0.072115] RIP: 0010:blk_mq_put_rq_ref+0xa/0x60
[ +0.000029] Code: 15 0f b6 d3 4c 89 e7 be 01 00 00 00 e8 cf fe ff ff 5b 41 5c 5d c3 0f 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 47 10 <48> 8b 80 c0 00 00 00 48 89 e5 48 3b 78 40 74 1f 4c 8d 87 e8 00 00
[ +0.000056] RSP: 0018:ffffb733c80bfb08 EFLAGS: 00010206
[ +0.000020] RAX: 0000000000000000 RBX: ffffb733c80bfb88 RCX: 0000000000000002
[ +0.001348] RDX: 0000000000000001 RSI: 0000000000000202 RDI: ffff97f14d9ad000
[ +0.001484] RBP: ffffb733c80bfb40 R08: 0000000000000000 R09: 0000000000000033
[ +0.001418] R10: 00000000000007cf R11: 000000000000000e R12: ffff97f14d9ad000
[ +0.001360] R13: ffff97f14df52000 R14: 0000000000000000 R15: 0000000000000001
[ +0.001341] FS: 00007f9a732e1f38(0000) GS:ffff97f0ffc00000(0000) knlGS:0000000000000000
[ +0.001419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.001401] CR2: 00000000000000c0 CR3: 0000000146402003 CR4: 00000000003726e0
[ +0.001399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ +0.001457] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

..eventuell ähnlich?

 

[Ingo S]

Ja, nicht nur ähnlich, sondern exakt das Problem, weshalb ich das Update mit dem neuen Kernel 5.13 gemacht habe. Dumm nur, das sich der Server jetzt komplett zerlegt hat durch das Netzwerkproblem.

 

[ITT]

Wie hast du deine bonds konfiguriert? active-backup?
EDIT: ...weil laut Log springt zB. bond0 zwischen den Interfaces hin- und her....?

 

[Ingo S]

Die bonds sind active-backup. Da ist auch meist nur ein Interface drin. Das sind deshalb bonds, damit man im Bedarfsfall einfacher ein Interface hinzufügen kann ohne den Link down zu nehmen. So war jedenfalls die Überlegung.
Das läuft auch schon seit Jahren so ganz problemlos.

Hier mal der dafür ausschlaggebende Teil der Network Config:

Spoiler: Netzwerk Config bonding

auto bond0
iface bond0 inet manual
        bond-slaves ens3f1
        bond-miimon 100
        bond-mode active-backup
#Client Access (Trunk)

auto bond2
iface bond2 inet static
        address 192.168.15.2/24
        bond-slaves ens3f0
        bond-miimon 100
        bond-mode active-backup
        bond-primary ens3f0
        mtu 9000
#Ceph (VLAN115)

auto bond1
iface bond1 inet static
        address 192.168.16.2/24
        bond-slaves enp3s0f0
        bond-miimon 100
        bond-mode active-backup
#Corosync (VLAN116)

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.4/24
        gateway 192.168.1.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

 

[ITT]

Seltsame config.... würde ich so nicht machen.
Wenn jetzt eh schon alles steht, korrigiere das doch mal.
EDIT: die IF-Names weichen aber ab (journal/config)? Ganz steig ich da nicht durch.

Hier ein Beispiel-Bond, wie ich es mache:

auto bond0 iface bond0 inet manual bond-slaves enp197s0f0np0 enp197s0f1np1 bond-miimon 100 bond-mode active-backup bond-primary enp197s0f0np0 mtu 9000

 

[Ingo S]

EDIT: die IF-Names weichen aber ab (journal/config)? Ganz steig ich da nicht durch.

Ja, das liegt daran, dass der betroffene Server VM-3 zur Zeit offline ist, damit er unser Ceph nicht ausbremst und hohe IO Latenz erzeugt. Die Config stammt daher von seinem "Bruder" VM-2, der hardwaremäßig identisch ist. Auf VM-3 haben sich nach dem Update die IF Namen verändert. Statt enp3s0f0 und -f1 gibt es dort jetzt enp4s0f0 und -f1
Sonst ist auf den Servern alles identisch, funktioniert einwandfrei.

Da das insgesamt 6 Server sind, im Produktivbetrieb und der Cluster jetzt aufgrund von "VM-3 offline" nun zu 100% voll ist, werde ich einen Teufel tun und die anderen Maschinen aus kosmetischen Gründen anfassen. Wie gesagt, da ist alles gut, das Bonding ist 100% nicht das Problem.

Wenn ich da bis heute Abend keine Lösung für finde, werde ich VM-3 aus dem Cluster werfen und neu installieren. Bis zum Wochenende will ich den Cluster wieder 100% in Ordnung haben. Keine Lust am Wochenende wegen irgendwas einspringen zu müssen

 

[Ingo S]

Ich habe am Freitag tatsächlich noch die Ursache für die "Netzwerkprobleme" gefunden.

Der Fehler lag zwischen den Kopfhörern. Hier ist also alles wieder in Ordnung.