[wiregate] Wieder Netzwerkproblem - monit?

[greentux]

Hallo zusammen,

ich hatte mal wieder den Fall, dass meine eth Schnittstelle entschlafen ist. Das WG war also nicht anpingbar und konnte auch selber nicht in die große weite Welt.
Ein Reboot und alles war gut. Ok, den Fehler haben wir vor einem Jahr noch nicht gefunden, erstmal egal.
Könnte man aber nicht dafür einen Watchdog realisieren? Wie könnte das, vermutlich mit den sowieso schon vorhandenen Komponenten, aussehen?

Der Ausfall eines Pings auf Host x für y Sekunden wäre zu detektieren, danach reboot.

Grüße

[greentux]

Es müsste folgender Bug sein:

#549606 - [linux-image-2.6.30-1-amd64] VIA-Rhine II network interface lost connectivity - Debian Bug report logs

Ist in 2.6.32-35 gelöst...

[marlan99]

Bei meinem Wiregate scheint diese version drauf zu sein:

Kernel and CPU: Linux 2.6.32-wiregate-1.31 on i586

Gruss
Marcel

[makki]

Ich hatte den Bug damals schon auf dem Radar, aber der trat mit (initialen 2.6.26) garnicht auf und wurde mit 2.6.32-10 behoben; Basis für den aktuellen Kernel ist 2.6.32-18.
Ausserdem betrifft der Bug auch nur die amd64-Betatester..

Das ausgetauschte tickert übrigens seither unauffällig auf meinem Schreibtisch, also HW-defekt wars keiner..

Interessant wäre trotzdem das "Packet of death" zu finden, auch wenn es das offenbar in mehreren hundert Installationen nur 2x gibt

Zurück zur Frage, das ist natürlich ein heftiger quirk (jedesmal wenn die Fritzbox ihre Tage hat zieht sich das WG auch selbst den Stecker!) aber einfach:
/etc/monit/enable/ping

 
check host gw with address 192.168.178.1
    if failed icmp type echo count 2 with timeout 1 seconds then 
	exec "/sbin/reboot"

(192.168.178.1 ist natürlich anzupassen!)

und danach ein

/etc/init.d/monit restart

Makki

[greentux]

Bist Du Dir ganz sicher, das der Patch im WG Kernel ist?

Ich könnte so eine Art tcpdump laufen lassen, der in einen Ringspeicher loggt. Muss ich mal ins Manual schauen, wie das ggf machbar wäre...
Der Switch wurde mittlerweile auch gegen einen HP getauscht.

[makki]

Ganz sicher.. Naja, fast ganz, die Zusammenhänge zwischen kernel.org, .deb, hunderten Patches, Changelogs usw. zu erfassen fällt auch mir im Einzelfall teils noch schwer..
Schätze mal wenn man nicht Linus oder Greg oder so heisst - und das behauptet - leidet man auch etwas an selbstüberschätzung

-> Um das nachhaltig auszusortieren hab ich jetzt mal nen neuen Kernel 2.6.32-current gebaut, glaube zwar nicht das da was ist aber schädlich ist es auch nicht.
Ich will den aber erst ein paar Tage hier auf den Testsystemen laufen sehen und würde ihn auch gerne selbst remote installieren weil das etwas tricky ist.. (wenig freier Platz, /boot ist Readonly gemountet, .. und bisher im Feld kein Kernel-Update notwendig war, daher kein ausgetretener Pfad)

Unabhängig davon das ich den schon 2x auf dem Radar hatte und der Bug hier einfach nicht zutrifft: kein Rhine-II sondern -III, kein amd64, kein APIC.. Könnte natürlich trotzdem sein das dies oder ähnliches unter bisher ungefundenen/undokumentierten Umständen auftritt.

Makki

P.S.: Da erinnere ich mich gerne daran, wie gut das ist, das ich mir am Samstag Abend falls nötig - auch wenns nur ein leiser Verdacht ist - ohne externe Hilfe einen neuen Kernel machen kann wenn ich will Auch wenns mir die Uptime von 447 days des WG1 versaut (das letzte mal wars die USV..)

[greentux]

ich hab mal noch genauer in die Logs geschaut und siehe da. Auch der Call Trace ist zu finden:

Jan 27 17:00:22 wiregate497 kernel: [79645.000041] ------------[ cut here ]------------
Jan 27 17:00:22 wiregate497 kernel: [79645.000301] WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0xcf/0x152()
Jan 27 17:00:22 wiregate497 kernel: [79645.000694] NETDEV WATCHDOG: eth0 (via-rhine): transmit queue 0 timed out
Jan 27 17:00:22 wiregate497 kernel: [79645.001030] Modules linked in: tun w83627hf hwmon_vid fuse loop ecb aes_i586 aes_generic ac snd_cs5535audio snd_ac97_codec ac97_bus parp
ort_pc snd_pcm parport snd_seq snd_timer snd_seq_device button processor snd geode_aes tpm_tis tpm tpm_bios soundcore snd_page_alloc geode_rng rng_core cs5535_gpio pcspkr seri
o_raw psmouse evdev ext2 mbcache dm_mirror dm_region_hash dm_log dm_snapshot dm_mod ide_gd_mod ide_pci_generic cs5536 usbhid hid amd74xx ide_core ata_generic ehci_hcd ohci_hcd
libata usbcore nls_base via_rhine scsi_mod mii thermal fan thermal_sys [last unloaded: scsi_wait_scan]
Jan 27 17:00:22 wiregate497 kernel: [79645.055344] Pid: 0, comm: swapper Not tainted 2.6.32-wiregate-1.31 #1
Jan 27 17:00:22 wiregate497 kernel: [79645.063606] Call Trace:
Jan 27 17:00:22 wiregate497 kernel: [79645.071648] [<c10253c5>] ? warn_slowpath_common+0x5e/0x8a
Jan 27 17:00:22 wiregate497 kernel: [79645.079737] [<c11bfe16>] ? dev_watchdog+0x0/0x152
Jan 27 17:00:22 wiregate497 kernel: [79645.087672] [<c1025423>] ? warn_slowpath_fmt+0x26/0x2a
Jan 27 17:00:22 wiregate497 kernel: [79645.095502] [<c11bfee5>] ? dev_watchdog+0xcf/0x152
Jan 27 17:00:22 wiregate497 kernel: [79645.103203] [<c1040a02>] ? clockevents_program_event+0xbd/0xcb
Jan 27 17:00:22 wiregate497 kernel: [79645.110847] [<c1041654>] ? tick_dev_program_event+0x1e/0x80
Jan 27 17:00:22 wiregate497 kernel: [79645.118378] [<c102ede1>] ? run_timer_softirq+0x185/0x1fc
Jan 27 17:00:22 wiregate497 kernel: [79645.125785] [<c1029c81>] ? __do_softirq+0x8e/0x130
Jan 27 17:00:22 wiregate497 kernel: [79645.133036] [<c1029d53>] ? do_softirq+0x30/0x3b
Jan 27 17:00:22 wiregate497 kernel: [79645.140160] [<c1029e12>] ? irq_exit+0x25/0x53
Jan 27 17:00:22 wiregate497 kernel: [79645.147133] [<c1004649>] ? do_IRQ+0x66/0x76
Jan 27 17:00:22 wiregate497 kernel: [79645.153928] [<c1003649>] ? common_interrupt+0x29/0x30
Jan 27 17:00:22 wiregate497 kernel: [79645.160615] [<c10164a0>] ? native_safe_halt+0x2/0x3
Jan 27 17:00:22 wiregate497 kernel: [79645.167135] [<c1007db9>] ? default_idle+0x50/0x70
Jan 27 17:00:22 wiregate497 kernel: [79645.173499] [<c10022f5>] ? cpu_idle+0x28/0x43
Jan 27 17:00:22 wiregate497 kernel: [79645.179694] [<c13126b8>] ? start_kernel+0x29d/0x2a0
Jan 27 17:00:22 wiregate497 kernel: [79645.185757] ---[ end trace a9b3f7df956de67e ]---
Jan 27 17:00:22 wiregate497 kernel: [79645.191904] eth0: Transmit timed out, status 0000, PHY status 786d, resetting...
Jan 27 17:00:22 wiregate497 kernel: [79645.208879] eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1

Kommt alle 10 Tage vor. Bei Deiner WG Battery im Büro ist derlei absolut nicht zu finden?

[makki]

Kommt alle 10 Tage vor. Bei Deiner WG Battery im Büro ist derlei absolut nicht zu finden?

Nee, natürlich nicht, sonst wär ich ja nicht so skeptisch
Wenns ein be/erkanntes generelles Problem gibt, bin ich bekanntermassen durchaus fähig, das auch in simplen Worten einzuräumen..

Mir ist trotzdem - auch wenns vermutlich ein brutaler Einzelfall ist - daran gelegen die Ursache zu finden.. Es ist ziemlich sicher nicht dieser Bug, aber vielleicht hat es damit zu tun, wer weiss, es gilt das Problem zu lösen, die Schuldfrage ist dann meine Sache bzw. für den Anwender unwichtig..

P.S.: Da sind ja nun keine 5 sondern hunderte WG im Feld, wo in nun gut 3J ein eindeutiger Bug noch nicht aufgefallen wäre -> Ergo ist es wenn etwas ziemliches spezielles aber ich mache lange genug IT um zu wissen das zwar >90% Layer 8 sind, aber sowas eben auch passiert, das es wie Layer 8 aussieht und nicht so ist. Das sind dann die seltenen, die in grossen Maschinen normalerweise verloren haben

-> Für die nächsten Tage schonmal einen guten Termin ausrechnen, wo ich draufkann und durchstarten darf.
-> Dann schliessen wir das systematisch 100% aus oder haben eine Ursache (nur hat so ein Kernel 2.6.32 by design einfach nicht so viele Knaller, wo das Netzwerk stehen bleibt sonst wären jeden Tag 1000 beliebte Webseiten nicht erreichbar )

Makki

[greentux]

Ich meinte jetzt nicht meinen Effekt, das das Netz weg ist, sondern erstmal den Trace im kernel log.
Mach doch mal einen "grep Trace" auf ein paar Kisten. Es würde mich nicht wundern, wenn da wenigstens mal dieser Trace aufträte.
Das der nicht direkt mit meinem Effekt in Zusammenhang zu bringen ist, sagt ja auch der letzte Kommentar im o.g. Bug.