[Berlin-wireless] ff_mapupdate friert olsrd ein

[Dennis Bartsch]

Hallo jow,

> Date: Sun, 2 May 2010 03:09:39 +0200
> From: xm at subsignal.org
> Hey Dennis.
> 
> Ja, olsrd-txtinfo ist kein seperater Prozess sondern hängt mit in der
> global mainloop drin, wenn etwas txtinfo ausließt dann kann olsrd nix
> anderes machen solange das Plugin mit senden beschäftigt ist, lässt sich
> auch olsr-seitig nicht fixen ohne wieder mit threads oder forks + ipc zu
> jonglieren.

Das Problem hier ist jedoch ein anderes: ff_mapupdate greift auf das latlon.js file zu, welches wiederum vom nameservice-plugin gefüllt wird, und blockiert es solange, wie wget hängt.

Mit Henning habe ich ja auch schon gesprochen: Er stellt sich vor, dass man den Zugriff auf das latlon.js asynchron gestaltet, so dass die Hauptschleife weiterlaufen kann. 
Dann wäre das Problem von OLSR-Seite behoben. Sollte aber ein Script, gerade bevor es im update_all-modus hunderte wgets (übrigens auch ohne timeout-parameter) auslöst, 
nicht vorher prüfen, ob das Ziel vorhanden ist? Auf unserem Uplinkrouter läuft das ganze als Shell-script, da habe ich den timeout auf 10s festgelegt und die Prüfung mit httping abgefackelt. 
Nur weiss ich nicht, wie das in Lua am besten gelöst wird.

> 
> Am besten einfach...
> 
> chmod -x /usr/sbin/ff_mapupdate
> 
> oder
> 
> echo 127.0.0.1 >> /etc/hosts.local

Nachdem die Ursache gefunden war, war ein Workaround schnell ausgerollt (ich habe die crontabs-zeile auskommentiert) ... 

> 
> ... bis das geregelt is.
> 
> ~ J.
Gruß
Dennis
 		 	   		  
_________________________________________________________________
http://redirect.gimas.net/?n=M1004xjajah2
Über Messenger günstiger telefonieren? Sagen Sie "Ja" zu JAJAH!
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20100502/0a80d34b/attachment.html>