wie Ihr bestimmt wisst stürzen bei uns im Tal die Supernodes aus unerfindlichen Gründen in die Wupper ab. Bisher dachte ich immer das liegt an meinem Unvermögen Arch richtig zu konfigurieren. Die Probleme fingen am 5. November an – zwei Tage zuvor wurde ein Update durchgeführt. Aus den Logdateien ist nichts zu erkennen. Die VM friert einfach so ein. Selbst in der VM-Konsole kann man sich nicht einloggen.
Da dies kein Dauerzustand sein kann und ich unsere Infrastrukturmenschen nicht ständig um Resets bitten möchte geschweige die Downtime des Freifunks zulassen darf, habe ich einen anderen Supernode, über den ich die totale Kontrolle habe, mittels ipip-Tunnel an einen der Übeltäter (w0) angeschlossen. 39 h ging alles gut. Ich dachte, es gibt nie wieder Probleme, bis ich Nachforschungen zu Routing-Problemen auf den Arch-Supernodes durchführen musste. Meine Gentoo-VM verabschiedete sich auch. Ich war aber im Stande folgendes zu erblicken:
auf w0 aus. w7 stürze ab. Das kann auch ein Zufall sein und die Ursache ist eine völlig andere. Der Hintergrund ist, das das Forum aus dem Wuppertaler Subnetz nicht erreichbar ist. Freitag morgens stimmte die Route noch. Gestern Abend und heute geht nichts mehr aus dem Freifunk ins Forum …
Hmm… die Traces der Kernel Panics zeigen leider nicht das Modul, in dem der Fehler aufgetreten ist. Wenn das nächste Mal so etwas passiert, kannst Du dann bitte einmal hochscrollen?
Ansonsten tippe ich auf das Modul batman_adv. Wir haben in keiner anderen Community jemals Kernel Panics beobachtet. Der auffälligste Unterschied zu den anderen ist, dass ihr Batman 2014 verwendet, der Rest ist noch bei 2013.
Danke Mic. Leider kann ich nicht hoch scrollen sonst hätte ich den gesamten Dump mitgeteilt. Die Kiste ist ja abgestürzt. Nach den Zeilen zu urteilen ist es irgendeine tun-Schnittstelle, also Bat15, fastd oder der Tunnel.
Ich schau mal wie ich den Dump für die Nachwelt sichern kann und melde mich dann.
Edit
kexec ist scharf und generiert mir einen Kernel Carsh Dump beim Kernel Panic. fastd ist nun auf Version 16. Außerdem habe ich die Link-Local-Adresse von der fastd Schnittstelle entfernt (nur für alle Fälle).
Ich habe nun die B.A.T.M.A.N.-adv-Entwickler verständigt. Matthias Schiffer, der fastd Entwickler, war so freundlich mir schnell zu erklären, dass fastd im Userspace läuft (somit niemals Kernel Panik auslösen kann) und ein Syscal den Bug im Kernel verursacht hat. Und da Batman ein Bestandteil des Kernels ist … natürlich bin ich mit der ganzen Sache überfordert, aber wir werden den Fehler schon finden. Ich liebe Open Source, nur da kann jeder wirklich mitmachen.
Es ist für die Freifunk-Nutzer zwar nicht schön, dass ihnen ständig die Server abstürzen und das Internet wegbricht; ich frage mich aber, ob man diesen Bug jemals im Labor provozieren könnte. Somit hat es auch was gutes wenn wir hier bat15 fahren und nicht bat14.
Fragt sich nur, ob dieser Bug dem Absturz der Arch-VMs ähnelt.
Kurzer Zwischenstand: auf w7 läuft nun ein von Martin Hundebøll gepatchtes Batman-adv Kernel Modul, welches den Fehler abfängt und mehr Informationen über die Ursache liefert. Und nun will seit 10 h kein Fehler passieren … ich hoffe und Tippe auf das Wochenende.
Es war ein langer Leidensweg. Bei jedem Absturz, jedes Mal den vmcore Dump zu extrahieren und auf der B.A.T.M.A.N. Mailingliste zu dokumentieren. Der Fehler kommt in unregelmäßigen Abständen, je nach Nutzerverhalten, und nimmt direkt den gesamten Server mit ins Nirvana. Bei mehreren Gateways ist es nur eine Frage der Zeit, bis das nächste Gateway das Gleiche erlebt. Ich kann doch nicht so einfach kommunizieren „Leute, tut mal bitte nicht das, was ihr tut, das mag der Server nicht“, denn entweder wird der Fehler gar nicht aufgedeckt oder irgend ein Depp macht genau das und ich kann mich dann gar nicht schlafen legen. Als ich getwittert habe, dass ich vorsichtshalber das Gateway deaktiviere, hatten wir 6 Tage Ruhe. Dann erwies sich auch 3.17.4 als instabil.
Der Patch von Martin Hundebøll wurde auf dem bestehenden, mit dem Kernel gelieferten bat-Kernelmodul angewendet und brachte am Wochenende statt Ergebnissen nur Frust und Verzweiflung. Als Sven Eckelmann ein ähnliches Problem bearbeitete, schlug Martin vor Svens Patch zusammen mit seinen Debugging-und-den-Kernel-von-Panik-abhaltenden-Routinen auf das bat-Modul im git anzuwenden. Wir bekamen Zahlen, die die Länge der fragmentierten Pakete beschrieben. Die Maschine konnte aber nicht vor einem Absturz bewahrt werden, da danach im Kernel immer etwas schief lief.
Dieser Bug wäre nicht aufgetreten, wenn die Anbindung an das FFRL-BB mit einer zum fastd-Tunnel identischen MTU von 1426 statt 1400 verwirklicht worden wäre. Somit hat es auch ein Gutes, dass der Bug entdeckt wurde. Wäre es nicht bei uns aufgetreten, wäre es woanders passiert. Ruben von FF NRW berichtet von hyperstabilem bat15, jedoch werden die Knoten dort anders angebunden.
Neben Frust, Verzweiflung und der für dieses Problem „gestohlenen“ Zeit auf der einen Seite habe ich andererseits als n00b, der kein C spricht, gelernt, wie man Fehler systematisch sucht, einen Kernel debuggt, Tunnel bohrt und Hilfe bei Entwicklern bekommt.