[Wien] oslrd hängt sich auf?
Josef Semler
(spam-protected)
Mi Jun 20 08:00:59 CEST 2012
Hi Tom,
das debuggin einer Trunk-Version vom Feb macht eher keinen Sinn, würd ich
sagen. Es sei denn, du willst dabei was lernen :-)
JA, wir hatten im Feb einige Versionen die speicher gefressen hatten. auch
auf den anderen plattformen.
Hab das aber nicht weiter verfolgt da es später nicht mehr aufgetreten ist.
Auch können wir hier nichts mehr verbessern, da der 2.4er Kernel im
Buildroot nicht mehr unterstützt wird.
Lass es. Mir wär lieber wir bauen was aktuelles mit den letzten Erfahrungen
und du testest auf Herz und nieren auf dem Buff.
Wenn du was stabiles für den Buffalo verwenden willst, nimm bitte die r1060
aus dem Contrib.
Die läuft im OZW als Router MEGA Stabil
LG Joe
--------------------------
Anm an alle: Die Versionen im Backfire Vienna Trunk sind deshalb im Trunk,
weil sie nie vollständig getestet wurden oder unvollständig sind. Wenn ich
größere defekte bemerke, lösch ich sie zwar oder schreib einen Vermerk ins
Log, aber dennoch ist das eine TESTUMGEBUNG.
Gesicherte Images, die allen Tests standhalten und der aktuellen
Zielsetzung entsprechen, finden den Weg ins Contrib.
Am 19. Juni 2012 18:35 schrieb (spam-protected) <(spam-protected)>:
> wifi-Script --> kA, vielleicht hab ich ihn auch einfach genau erwischt
> wie ers gestartet hat, ist ja nur eine Zustandsaufnahme.
> pingloop.sh ist mein eigenes script um den zustand des routers zu
> überprüfen (siehe anhang)
>
> werd mir deine vorschläge ansehn wenn ich heimkomm, und den router
> mittels restartet wieder erreichbar gemacht hab. wobei ich jetzt nicht
> wirklich weiß wie ich das machen soll, aber ich werds vielleicht per
> googeln rausfinden.
>
> LG, Thomas
>
> Am 19. Juni 2012 17:48 schrieb Erich N. Pekarek <(spam-protected)>:
> > Hallo!
> >
> > Wieso läuft das wifi-Skript? Das sollte doch gleich wieder beendet
> werden??
> > Was ist pingloop.sh?
> > Dnsmasq bitte mit --bind-interfaces und --interface=lo aufrufen
> (allenfalls
> > Lan-Interface hinzufügen). Damit ist einmal der Speicherverbrauch dadurch
> > überschaubar. Siehe /etc/dnsmasq.conf (sic!)
> > Ssh kannst Du einmal auf einen anderen Port legen. Das ist zwar nicht
> > sicherer, aber es sollten vorerst weniger Verbindungsversuche von außen
> > kommen.
> >
> > Lg
> > Erich
> >
> > Am 2012-06-19 14:10, schrieb (spam-protected):
> >
> >> Soo, habs jetzt beim zweiten Anlauf geschafft upzudaten, folgende
> >> Versionen werden mir jetzt gemeldet:
> >>
> >> BusyBox v1.15.3 (2012-02-20 21:46:19 CET) built-in shell (ash)
> >> * OpenWRT (backfire, r30662)
> >> * LuCI (trunk, r8314)
> >> * 0xFF-Snapshot r1133 by JoeSem
> >>
> >> Leider trotzdem weiterhin das problem, das der RAM-Verbrauch anwächst
> >> bis das System einfriert -->
> >>
> >>
> >> processes and stats:
> >> Mem: 14080K used, 256K free, 0K shrd, 352K buff, 996K cached
> >> CPU: 0% usr 99% sys 0% nic 0% idle 0% io 0% irq 0% sirq
> >> Load average: 4.92 2.64 1.27 8/26 20254
> >> PID PPID USER STAT VSZ %MEM %CPU COMMAND
> >> 20246 996 root R 1528 11% 21% /bin/sh /sbin/wifi
> >> 299 1 root R 1432 10% 16% udhcpc -t 0 -i eth0.1 -b -p
> >> /var/run/
> >> 940 1 root R 7348 51% 14% /usr/sbin/olsrd -f
> >> /var/etc/olsrd.con
> >> 20251 1243 root R 1428 10% 12% top -b -n 1
> >> 1032 1 root R 1440 10% 10% crond -c /etc/crontabs -l 9
> >> 926 1 nobody R 860 6% 9% /usr/sbin/dnsmasq -K -D -y -Z
> -b
> >> -E -
> >> 4 1 root RW 0 0% 8% [kswapd]
> >> 20214 1 root S 1668 12% 5% /bin/sh /sbin/hotplug-call
> iface
> >> 1 0 root S 1432 10% 5% init
> >> 8 1 root SW 0 0% 1% [mtdblockd]
> >> 20253 20214 root S 1668 12% 0% /bin/sh /sbin/hotplug-call
> iface
> >> 148 1 root S 1440 10% 0% syslogd -C16
> >> 1000 999 root S 1440 10% 0% -ash
> >> 907 1 root S 1432 10% 0% /usr/sbin/uhttpd -f -h /www -r
> >> bufpan
> >> 118 1 root S 1432 10% 0% init
> >> 1243 1000 root S 1428 10% 0% /bin/sh ./pingloop.sh
> >> 150 1 root S 1424 10% 0% klogd
> >> 996 1 root S 1192 8% 0% /usr/sbin/ffwatchd
> >> 999 899 root S 1188 8% 0% /usr/sbin/dropbear -P
> >> /var/run/dropbe
> >> 899 1 root S 1112 8% 0% /usr/sbin/dropbear -P
> >> /var/run/dropbe
> >> 20254 20253 root R 860 6% 0% /sbin/uci -P /var/state -q get
> >> firewa
> >> 3 1 root SWN 0 0% 0% [ksoftirqd_CPU0]
> >> 2 1 root SW 0 0% 0% [keventd]
> >> 6 1 root SW 0 0% 0% [kupdated]
> >> 94 1 root SWN 0 0% 0% [jffs2_gcd_mtd4]
> >> 5 1 root SW 0 0% 0% [bdflush]
> >>
> >> uptime:
> >> 19:29:16 up 1:45, load average: 6.09, 3.04, 1.42
> >>
> >>
> >> Letzte Woche hat sich der Router ca 6 Stunden nach dem Einfrieren
> >> wieder ansprechen lassen, und hat während des Eingefrohren-seins
> >> (fast) alles an Prozessen abgewürgt was gelaufen ist. Hab dann manuell
> >> den olsrd wieder gestartet und hatte die ganze Woche (fast)
> >> durchgehende Verbindung. Jetzt die Frage ob ich vielleicht gezielt die
> >> Luci auf- und abdrehen kann, um diesen Zustand reproduzieren zu
> >> können.
> >>
> >> LG, Thomas
> >>
> >> Am 7. Juni 2012 20:46 schrieb Joe Semler<(spam-protected)>:
> >>>
> >>> Schau mal auf oe1xrw.ozw und such dir die Version aus dem Trunk.
> >>> Bei uns am Berg läuft die wochenlang ohne dass sie jemand angreift.
> >>> 1060 ist schon eher alt :-)
> >>>
> >>>
> >>> Am 07.06.2012 um 12:41 schrieb "(spam-protected)"<(spam-protected)>:
> >>>
> >>>> Sooo.. nachdem ich auf dem Router nun das ff_mapupdate verschoben
> >>>> habe, hab ich jetzt wieder mal das Problem, dass der RAM-Verbrauch des
> >>>> oslrd Prozesses kontinuierlich anwächst, bis nach ein paar Stunden
> >>>> kein RAM mehr da ist, und der Router einfriert und nur mehr per Ping
> >>>> auf der LAN-Seite erreichbar ist, aber nicht mehr auf port 22 oder 80
> >>>> antwortet.
> >>>>
> >>>> nach dem booten fängt der oslrd Prozess ca mit 17% RAM an:
> >>>> 03:59:02 up 15 min, load average: 0.06, 0.14, 0.12
> >>>> 939 1 root S 2500 17% 0% olsrd -f /var/etc/olsrd.conf
> >>>> -nofork
> >>>>
> >>>> 05:00:23 up 1:16, load average: 0.29, 0.25, 0.20
> >>>> 939 1 root S 5464 38% 0% olsrd -f /var/etc/olsrd.conf
> >>>> -nofork
> >>>>
> >>>> 05:24:42 up 1:40, load average: 1.59, 0.83, 0.54
> >>>> 939 1 root S 6440 45% 8% olsrd -f /var/etc/olsrd.conf
> >>>> -nofork
> >>>>
> >>>> 05:38:59 up 1:55, load average: 6.62, 4.36, 2.34
> >>>> 939 1 root R 6820 47% 10% olsrd -f /var/etc/olsrd.conf
> >>>> -nofork
> >>>>
> >>>> ----> dead
> >>>>
> >>>>
> >>>>
> >>>> Am 7. Juni 2012 08:07 schrieb Markus
> >>>> Kittenberger<(spam-protected)>:
> >>>>>
> >>>>> wirf mal den ramfressenden "schrott" vom router,..
> >>>>>
> >>>>> z.b.: rm /usr/sbin/ff_mapupdate
> >>>>>
> >>>>> evt beendet sich der olsrd ja nur weil er keinen ram mehr allokieren
> >>>>> kann,..
> >>>>> (btw sagt der syslog irgendwas intressantes?)
> >>>>>
> >>>>> und ja updaten schadet dann trotzdem nicht,..
> >>>>>
> >>>>> evt kannst du olsrd package aus trunk nehmen (ist aber idr für neuere
> >>>>> uclibc)
> >>>>> für alte uclibc hab ich neue olsrd meist hier (inklusive ipkgs und
> >>>>> paketquellen)
> >>>>> http://193.238.157.78/~markus/olsrd/cross/
> >>>>>
> >>>>> (allerdings schon für sehr alte uclibc, da schon lange keine neuen
> >>>>> corsscompile targets in mein buidsystem integriert)
> >>>>>
> >>>>> und sonst bleibt halt selber kompilieren
> >>>>>
> >>>>> 2012/6/7 (spam-protected)<(spam-protected)>
> >>>>>
> >>>>>> Gibts fürs olsrd updaten ne Anleitung irgendwo?
> >>>>>>
> >>>>>> Ich habe nachdem ich gestern am Abend einen hard-reboot (mittels
> >>>>>> Netzteil ziehen und wieder anstecken) gemacht hab heute in der Früh
> >>>>>> schon wieder keinen olsrd prozess mehr, aber der Prozess
> >>>>>> "/usr/sbin/ffwatchd" ist weiterhin da (und frisst 12% RAM)
> >>>>>>
> >>>>>> Weiters hab ich 12 Instanzen von "/bin/sh -c /usr/sbin/ff_mapupdate"
> >>>>>> die den Rest des RAMs verschlingen. Ihr habt ja gesagt dass ist nur
> >>>>>> für GPS-Koordinaten austauschen oder irgendsowas, würds vielleicht
> >>>>>> helfen wenn ich ihm einfach das script umbenenne, dass ers nicht
> mehr
> >>>>>> ausführen kann?
> >>>>>>
> >>>>>> LG, Thomas
> >>>>>>
> >>>>>> Am 7. Juni 2012 00:23 schrieb Markus Kittenberger
> >>>>>> <(spam-protected)>:
> >>>>>>>
> >>>>>>> uralter olsrd, zuerst updaten,. (-;
> >>>>>>>
> >>>>>>> (0.6.3 kommt/ist grad raus)
> >>>>>>>
> >>>>>>> lg Markus
> >>>>>>>
> >>>>>>> 2012/6/6 (spam-protected)<(spam-protected)>
> >>>>>>>
> >>>>>>>> vom joe, ausm contrib
> >>>>>>>>
> >>>>>>>> 0xFF-Backfire Vienna 1.2 (r1060)
> >>>>>>>> Powered by LuCI Trunk (v0.10+svn7030)
> >>>>>>>>
> >>>>>>>> ich glaube es war das hier:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ftp://oe1xrw.ozw.wien.funkfeuer.at/contrib/brcm-2.4/openwrt-brcm-2.4-squashfs.trx
> >>>>>>>> aber da bin ich mir nicht mehr ganz sicher. schon wieder länger
> her.
> >>>>>>>>
> >>>>>>>> Am 6. Juni 2012 22:44 schrieb gerhard poller<(spam-protected)>:
> >>>>>>>>>
> >>>>>>>>> und welche firmware
> >>>>>>>>>
> >>>>>>>>> selbstgebaute openwrt ?
> >>>>>>>>> oder die von joe ?
> >>>>>>>>>
> >>>>>>>>> hf akku
> >>>>>>>>> Am 06.06.2012, 22:40 Uhr, schrieb Markus Kittenberger
> >>>>>>>>> <(spam-protected)>:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> welche oslrd version?
> >>>>>>>>
> >>>>>>>> *** olsr.org - 0.6.1-git_-hash_b566ecdfe66464cd142833673600eaa1
> -
> >>>>>>>> ***
> >>>>>>>> Build date: 2011-05-06 01:22:22 on alpha
> >>>>>>>>
> >>>>>>>> LG, Thomas
> >>>>>>>>
> >>>>>>>>>> 2012/6/6 (spam-protected)<(spam-protected)>
> >>>>>>>>>>
> >>>>>>>>>>> Hab in letzter Zeit öfters das Problem, dass sich auf meinem
> >>>>>>>>>>> Buffalo
> >>>>>>>>>>> Router der OSLR Deamon aufhängt. Bekomme dann keinen Verbindung
> >>>>>>>>>>> zu
> >>>>>>>>>>> Funkfeuer mehr, und die luci web-gui gibt folgende
> Fehlermeldung:
> >>>>>>>>>>>
> >>>>>>>>>>> OLSR Daemon
> >>>>>>>>>>> Unable to connect to the OLSR daemon!
> >>>>>>>>>>> Make sure that OLSRd is running, the "txtinfo" plugin is
> loaded,
> >>>>>>>>>>> configured on port 2006 and accepts connections from
> "127.0.0.1"
> >>>>>>>>>>>
> >>>>>>>>>>> Nach einem Neustart des Routers funktioniert wieder alles wie
> es
> >>>>>>>>>>> sollte.
> >>>>>>>>>>> Bitte um Hilfe wie ich das Problem debuggen könnte, oder was
> ich
> >>>>>>>>>>> dagegen tun könnte.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> LG, Thomas
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Wien mailing list
> >>>>>>>>>>> (spam-protected)
> >>>>>>>>>>> https://lists.funkfeuer.at/mailman/listinfo/wien
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Erstellt mit Operas revolutionärem E-Mail-Modul:
> >>>>>>>>> http://www.opera.com/mail/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Wien mailing list
> >>>>>>>>> (spam-protected)
> >>>>>>>>> https://lists.funkfeuer.at/mailman/listinfo/wien
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Wien mailing list
> >>>>>>>> (spam-protected)
> >>>>>>>> https://lists.funkfeuer.at/mailman/listinfo/wien
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>> --
> >>>> Wien mailing list
> >>>> (spam-protected)
> >>>> https://lists.funkfeuer.at/mailman/listinfo/wien
> >>
> >> --
> >> Wien mailing list
> >> (spam-protected)
> >> https://lists.funkfeuer.at/mailman/listinfo/wien
> >
> >
> >
> > --
> > Wien mailing list
> > (spam-protected)
> > https://lists.funkfeuer.at/mailman/listinfo/wien
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20120620/49676e50/attachment.htm>
Mehr Informationen über die Mailingliste Wien