Die Server des Kreises Warendorf crashen neuerdings regelmäßig. Wir untersuchen das.
Ich glaube wir sollten uns mal an das große Forum wenden. Vielleicht gibt es bei L2TP noch Sachen, die wir tun können, um die Stabilität zu erhöhen.
Das sind doch Einkerner, oder?
Die craschen offenbar immer an der gleichen Stelle. Ich habe diesmal einen kernel-trace:
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.987373] batman_adv: bat0: Interface deactivated: l2tp1701
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.987378] batman_adv: bat0: Removing interface: l2tp1701
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999056] ------------[ cut here ]------------
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999079] WARNING: CPU: 0 PID: 11249 at /build/linux-SM8oso/linux-4.2.6/net/batman-adv/bat_iv_ogm.c:522 batadv_send_outsta
nding_bat_ogm_packet+0x80/0xe0 [batman_adv]()
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999081] Modules linked in: ipt_REJECT nf_reject_ipv4 xt_multiport iptable_filter binfmt_misc batman_adv crc32c_generic l
ibcrc32c bridge stp llc ip6table_mangle ip6_tables xt_TCPM
SS xt_tcpmss xt_tcpudp iptable_mangle xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables x_tables dummy ip_gre ip_tunnel gre ppdev psmouse ttm pcspkr serio_raw acpi_cpufreq evdev drm_kms_helper joydev processor drm thermal_sys parport_pc parport i2c_piix4 8250_fintek button l2tp_eth l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel nf_conntrack_netlink nfnetlink nf_conntrack loop autofs4 hid_generic usbhid hid ext4 crc16 mbcache jbd2 dm_mod sg sr_mod cdrom ata_generic virtio_net virtio_blk ata_piix floppy uhci_hcd ehci_hcd virtio_pci virtio_ring virtio libata scsi_mod usbcore usb_common
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999133] CPU: 0 PID: 11249 Comm: kworker/u2:0 Not tainted 4.2.0-0.bpo.1-amd64 #1 Debian 4.2.6-3~bpo8+2
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999135] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999141] Workqueue: bat_events batadv_send_outstanding_bat_ogm_packet [batman_adv]
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999269] ffff88003bb83da0 0000000000000018 ffffffff81554521 0000000000000000
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999272] ffffffff8106fa01 ffff88003d311c38 ffff88003bcd9000 ffff88003bcd9980
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999274] ffff88003d311c00 ffff88003e2c1100 ffffffffa048b4a0 ffff88003e2c1100
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999283] Call Trace:
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999308] [<ffffffff81554521>] ? dump_stack+0x40/0x50
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999324] [<ffffffff8106fa01>] ? warn_slowpath_common+0x81/0xb0
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999334] [<ffffffffa048b4a0>] ? batadv_send_outstanding_bat_ogm_packet+0x80/0xe0 [batman_adv]
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999342] [<ffffffff8108672a>] ? process_one_work+0x14a/0x3d0
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999346] [<ffffffff81087115>] ? worker_thread+0x65/0x470
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999358] [<ffffffff81555d0f>] ? __schedule+0x28f/0x8b0
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999362] [<ffffffff810870b0>] ? rescuer_thread+0x2f0/0x2f0
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999366] [<ffffffff8108c593>] ? kthread+0xd3/0xf0
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999369] [<ffffffff8108c4c0>] ? kthread_create_on_node+0x170/0x170
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999373] [<ffffffff8155a19f>] ? ret_from_fork+0x3f/0x70
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999376] [<ffffffff8108c4c0>] ? kthread_create_on_node+0x170/0x170
Jan 9 12:32:23 ffwaf-srv2 kernel: [47150.999378] ---[ end trace ce5cfa781c15b362 ]---
Jan 9 12:32:23 ffwaf-srv2 dhcpd: DHCPREQUEST for 10.43.113.133 from 40:f3:08:xx:xx:xx (android-xxxxx) via dom1-mesh
Jan 9 12:32:23 ffwaf-srv2 dhcpd: DHCPACK on 10.43.113.133 to 40:f3:08:xx:xx:xx (android-xxxxx) via dom1-mesh
Jan 9 12:32:24 ffwaf-srv2 ntpd[1446]: Deleting interface #99 l2tp1701, fe80::943f:fcff:fe8f:8448#123, interface stats: received=0, sent=0, dropped=0, active_time=1383 secs
Jan 9 12:32:24 ffwaf-srv2 ntpd[1446]: peers refreshed@jotzt, DRINGEND: Ich habe den Knoten ffwaf-enniger-kapellenstr-01 im Verdacht. Mach den bitte mit einer stable Version fertig. Es ist ja ein 841v9-er.
Ich kümmere mich ASAP.
Kann es auch an diesem liegen:
http://ffwaf-srv2.freifunk-muensterland.net/map/#!v:m;n:60e327c78058
Da lief ursprünglich ein V9er mit der stable, der blieb häufiger komplett hängen. Jetzt hängt da ein V10 dran, es scheint aber immer noch Probleme zu geben. Ich vermute daher, dass die Probleme evtl. am Uplink liegen. Gibt es da eine Möglichkeit?
Ist für heute 18:20 terminiert.
EDIT: Seit 18:22 läuft der Knoten auf „stable“.
Kurz vor den Crash ist immer ein Tunnel runter gefahren, weil die Gegenstelle nicht mehr ging. Kann sehr gut mit einer schlechten Verbindung zusammen hängen. Das der Server dann aussteigt geht aber nicht. Hab nen Bug eröffnet. Vor Ort DSL ünrtprüfen wäre gut.
Jupp. Bin am Ball.
Das sind beides krumpelige DSL RAM-Anschlüsse. Was wäre da zu prüfen? Fehlerrate der Verbindung?
Frage ist, ob die CPE am DSL Bitfehler misst. Falls ja, den Anschluss entstören lassen.
Irgendwelche Veränderungen seit der Umstellung erkennbar?
Abwarten. Danke für den Einsatz.
Die Dinger crashen zwar immer noch einmal am Tag, wurden aber so eingestellt, dass sie dann sofort rebooten (und vorher noch crash-information wegschreiben). So ein Ausfall dauert ca. 1min. Ab und an gibt es also mal einen Hänger, wenn der Knoten gerade mit dem crashenden Server verbunden ist…
Keine Änderung: die Teile gehen ca. 1x Tag in die Knie. Ich habe nicht die Kompetenz das auf der Ebene zu untersuchen, habe aber einen Bug bei den batman Entwicklern eröffnet.
1 „Gefällt mir“