Wir haben seit 35 Tagen gluon 2017.1.3 auf den Beta-Nodes und mich irritiert, dass keiner der Nodes eine Uptime grösser als 11 Tage hat. Beschwerden über die Performanz oder Abstürze gab es keine. Wie sieht es bei Euch aus?
Es gibt communities, die haben „weekly reboot“ oder gar „daily reboot“, da wirst Du also -außer bei defekten Knoten- nie eine Uptime von mehr als 7 Tagen sehen.
Ansonsten wird vortrefflich gerätselt z.B. in
Letztlich läuft es leider immer wieder heraus auf: "Euer Layer-2-Netz ist größer als 500/400/300/200/100 Knoten, das ist normal"
(Wert bitte so wählen, dass der Anfragende klar darunter fällt und der Effekt damit offiziell für erklärt betracht werden kann und dann die Diskussion um „Wie ein Netz teilen“ in die Geschmacksrichtungen „Hood-Selektor“, „Domain-Selektor“, „babel-gluon“ o.ä. derailen kann.)
Wenn Du also jetzt die Frage bekommen solltest „Wie groß ist euer Netz denn“: Gar nicht erst mit einem Zahlenwert antworten, sondern gleich mit „zu groß“, das beschleunigt die Diskussion um mindestens zwei Schritte.
(Sorry für den Sarkasmus, es ist wirklich nicht persönlich gemeint, aber ich sehe wenig Chancen, dass die Diskussion diesmal etwas anderes ergibt.)
ich habe jetzt doch mal geschaut.
Mehrl als 800 Knoten in einer einzigen Layer2-Domain?
Da muss ich nun leider wirklich sagen: Da wäre „Uptime von nur wenigen Tagen“ meine geringste Sorge.
@kjo Ich würde mir wirklich keine Gedanken drum machen. Das ist völlig zu verschmerzen. Angesichts der Domain-Größe würde mich selbst eine Uptime von durchschnittlich nur einem Tag nicht überraschen.
Der Vorteil von Gluon, grundsätzlich keine Vorab-Planung und -Koordination zu benötigen, geht flöten, wenn schon dreistellige Knotenzahlen aus dem Nutzungsszenario ausgeschlossen werden. Für drölfzig SSIDs im Ort, wäre imho libremesh.org der Ansatz der Wahl — oder ›traditionelles‹ Freifunk-Meshkit.
Wer rebootet den Knoten denn? Ist das der watchdog, der beschliesst dem Leiden ein Ende zu bereiten oder schiesst sich der Knoten selbst mir irgendeinem Kniff frei?
Welche Prozesse benoetigen denn einen Reboot? Das ist eigentlich nicht „unixlike“.
evtl(!) hat die Firmware Watchdog-Progzesse, die feststellen, dass z.B. der Wifistack auf bestimmte Anfragen nicht mehr reagiert.
Das kann man mit einer endlosen Bastelei zur Laufzeit korrigieren, immer in der HOffnung, dass nicht noch weiterer, nicht erkannter Schaden in irgendwelchen Tabellen ist.
Ja, das sind Bugs, sehr schwere Bugs.
Aber wenn Dir ein Reboot in so einer Situation nicht „unixlike“ ist: Linux ist dann vermutlich „eh nur ein Kinderunix“ für Dich.
Dann geh’ halt zu free/net/openbsd. Schönen Abend noch.
Noe, fuer mich ist das ein richtiges Unix und ich glaub nicht, dass die BSD-Nischen da besser aufgestellt sind, ich warte da lieber auf GNU Hurd.
Danke fuer die Informationen.
Wie Du richtig feststellst gibt es Knoten, die aus bislang dubiosen Gründen einen Reboot hinlegen.
Es gibt auch Knoten, die einfach in irgendeinem Zombie-Status verharren, z.b. weil ihnen das Wifi wegbricht und sie keinen LAN/WAN-Uplink haben. Oder bei denen der Respondd nicht mehr antwortet, aber Nachbarknoten sehen noch seine OGM-Pakete.
An dieser Stelle gibt es -seit vielen Monaten/Jahren- eine auch strategisch/ideologisch gefärbte Debatte über das richtige Vorgehen:
Entweder trickreiche Watchdog-Scripte, die mögliche instabile Zustände frühzeitig zu erkennen versuchen und nach ggf. einem einzelnen „Fix-Versuch“ (gestorbenen Dienst nochmal starten… interface down/up) bei erneutem Fail beim Wiederholcheck einen Reboot machen. Lokal ist der funktionsfähige, möglichst verfügbare Knoten wichtig. Im Zweifelsfall lieber ein Reboot mehr als Stundenlang einen „geht nicht so richtig“-Knoten zu haben.
Oder striktes „Muss upstream gefixt werden“: Reported Bugs, installiert externe Syslog-Server, hängt Terminals an Serielle Konsolen, beteiligt Euch beim Testen von Master-Build. Hotfix-Scripte reduzieren den „Druck auf dem Kessel“ und die ungefixten Bugs werden immer zahlreicher.
Welcher Linie man dabei folgt hängt nicht nur davon ab, was man mit Freifunk vor Ort tut, sondern auch stark davon, was man technisch und auch organistatorisch überhaupt zu leisten vermag.
Ich glaube, beides ist richtig. Natürlich ist es schöner, wenn ein Prozess oder das ganze Gerät stabil läuft. Aber das ist ein Ideal, was selten erreicht wird.
Noch dazu kommt, dass es nicht genug Entwickler gibt, die sie in die Details der Treiberentwicklung reindenken können. Daher ist es oft ein notwendiger Kompromiss mit Wächterskripten zu arbeiten.
Ich bin mir nicht sicher, ob das allen, die dankenswerterweise etwas dazu gesagt haben klar ist: Wir haben seit Mai 2017 Gluon 2016.2.3 auf allen 800 Nodes und das Netz und die einzelnen Nodes sind wider Erwarten immer noch stabil. Das war mit allen Gluon Versionen die wir davon hatten auch so. Ich möchte sehr gerne auf 2017.1.3 updaten, einzig und allein wegen des spektakulären RCE Bugs im dnsmasq. Aber wenn in der Release ein noch unerkannter Bug steckt, der die Nodes crashen lässt, dann fixe ich lieber erstmal den dnsmasq in gluon 2016.2.3 und warte ab.
habt ihr denn nun irgendwelche watchdogs/workaround/reboot-scripte drin in euren Knoten mit 2017.1.3 @kjo ?
zudem: eigentlich sollten wenn dann nur Knoten mit 32MB RAM betroffen sein, nicht die mit 64 oder mehr.
Kannst du das mal nachprüfen?
Die Instabilitäten/reboots in den beiden verlinkten Issues kommen durch höhere RAM-Auslastung, die bei kritischen Werten kernel-seitig zu einem Reboot führt, um das System wieder zu stabilisieren.
Daher sind z.B. Knoten mit vielen Mesh-Nachbarn (wifi / kabel) stärker davon betroffen als andere.
Geräte die nur meshen kann man „schonen“, indem man fastd deaktiviert, wenn er sowieso nicht genutzt wird.
weiterhin wäre interessant, ob die Uptimes alle ziemlich gleich lang sind - dann spricht das sehr stark gegen einen Bug, eher für Stromausfall oder wiederum watchdogs/workaround/reboot-scripte
Wir haben das gluon 2017.1.3 überhaupt nicht modifiziert. Die beiden (Mi)-cronjobs sind autoupdate und alfred.
Betroffen sind die Nodes unabhängig von der Hardware. Kannst Du hier sehen:
Nach Firmware sortieren und dann die Uptimes vergleichen, dass da viele mit nur wenigen Tagen bei sind fällt sofort ins Auge. Natürlich will mein Node zu hause, jetzt wo ich in beobachte nicht abstürzen. Hat schon 13 Tage uptime und hat 6MB RAM frei.
