[Berlin-wireless] S70freifunkmap

[Marco Tidow]

On Tue, Jun.12. 14:12 +0200, Stefan Sperling wrote:
> On Tue, Jun 12, 2007 at 03:29:57AM +0200, Marco Tidow wrote:
> > update () {
> >   # only one instance should be running at time
> >   # if exists an other one kill them and all wgets
> >   pid="$(cat /tmp/freifunkmap.pid 2>/dev/null)"
> >   if [ ! -z $pid ]; then
> >     kill $pid >/dev/null 2> /dev/null
> >   fi
> 
> Das ist für WRTs OK, aber nicht besonders portabel.
> 
> Der code killt keine falschen Prozesse solange PIDs immer
> aufsteigend sind. Das ist bei Linux der Fall.

ack.  war mir zuviel aufwand, den check für wget´s auch hier noch
analog einzubauen.

asfaik ein prinzipielles problem, daß auch tools wie pidof haben,
man muß das wohl schon den kernel selbst erledigen lassen, bin an der stelle
aber nicht auf dem laufenden.


> Warum muss man denn die wgets eigentlich killen?
> Das schlimmste was passieren kann ist doch das auf layereight.de
> ein paar http verbindungen rumidlen, oder? Wen stört das?

auf einem 8MB-router sind diese leichen schon relevant.
man denke an olsr-laptop´s in der nachbarschaft, die plötzlich offline sind,
-> wget hängt

von nicht ganz so "tollen links" (tm? ;-) und nicht forward´enden
möchtegern-olsr-aber-nicht-ohne-blockende-firewall-nodes ganz zu schweigen.

hier fehlt auch in meiner schon ziemlich verschlankten version noch ein check,
LQ unter 50% ? skip : fetch

macht die map nur informativer, daß garnicht erst links suggeriert werden, wo
keine sind (wenn man die router mit rate=mrate betreibt, um so mehr)


> Locking wäre halt der "korrekteste" Weg.
könnte man zur not auch mit named-pipe´s realiseren, das dort kernel-seitig
impliziete locking (reader/writer) anstelle zusätzlicher binaries verwenden.
kostet aber asfair min. einen weiteren (shell-)prozeß ->RAM :-(

> In der Praxis reicht es aber auch völlig ohne locking zu fahren und
> das script nur täglich statt stündlich oder minütlich auszuführen.
> Das ist auch portabel und für die Praxis "korrekt" genug :)

weiß nicht, geht auch auf den kleinen kisten gut "hourly", setze das zumindest
so;  denke, das tagsüber ein bißchen absinkende link-niveau zu visualisieren,
ist ganz nützlich.

nachts, wenn das default-daily update ( ca. 00:00 ) guckt, laufen auch die
verrücktesten reflektionen mit LQ 1.0


dot-draw ist für richtig zeitnahe darstellungen natürlich ungeschlagen.

Gruß, marco