[Wien] oslrd hängt sich auf?

Erich N. Pekarek (spam-protected)
Di Jun 19 17:48:22 CEST 2012


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





Mehr Informationen über die Mailingliste Wien