[PATCH] fff-hoods: remove dependency to /tmp/started

[Adrian Schmutzler]

Hallo Fabian,

> -----Original Message-----
> From: Fabian Bläse [mailto:fabian at blaese.de]
> Sent: Freitag, 3. August 2018 12:53
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; franken-dev at freifunk.net
> Cc: Tim Niemeyer <tim at tn-x.org>
> Subject: Re: [PATCH] fff-hoods: remove dependency to /tmp/started
> 
> Hallo Adrian,
> 
> > On 3. Aug 2018, at 12:43, Adrian Schmutzler <mail at adrianschmutzler.de>
> wrote:
> >
> > Hallo,
> >
> > ich habe gerade mal wieder über das Thema nachgedacht.
> >
> > Es kommt ja gelegentlich vor, dass configurehood hängt, und dann wird es
> zigmal
> > gestartet. Das würde dieser Patch beheben.
> 
> Das ist auch der Teil aus diesem Patch, den ich unbedingt gerne hätte.
> Der Patch zielt damit aber darauf ab, /tmp/started los zu werden, was du ja in
> dieser Form nicht wolltest.

Den Teil mit dem einmal ausführen finde ich für sich auch gut, ich bin mir nur nicht sicher, ob das hilft.

> 
> Hier sollte man mal eine Lösung finden, die sicherstellt, dass configurehood (und
> ggf. auch die Firewall wie festgestellt wurde) erst nach configurenetwork laufen
> können.

Was ja das ist, was /tmp/started hervorragend leistet. Es ist nur nicht schön, wir brauchen also ggf. eine "bessere Lösung".

> 
> > Die Konsequenz wäre aber, dass dann das ursprüngliche configurehood
> solange
> > alleine läuft, bis es "fertig ist". Hängt es allerdings wirklich, wird es nie
> > fertig und der Router hängt auch.
> 
> Was aber keinen Unterschied macht. Wenn ein configurehood hängt, hängen
> alle.
> Mein Gefühl sagt mir aber, dass das nur passiert, wenn configurehood mehrfach
> läuft (z.B. wenn man es manuell startet) und das also ein
> Nebenläufigkeitsproblem ist.

Bei mir tritt das auch manchmal einfach so auf, ohne dass jemand manuell configurehood startet.

> 
> >
> > Wäre es nicht irgendwie sinnvoller, einen Mechanismus zu finden, der ein
> > hängendes configurehood abschießt?
> 
> Bisher hat das noch nie was geholfen. Bei mir äußerte sich immer in
> irgendeinem Lock auf den Wireless Interfaces, das nicht frei wurde, wenn ich
> die Meldung richtig im Kopf habe.

Ja, genau. Aber wenn configurehood dann drölfzig Mal gestartet wird, hört das Lock nie mehr auf. Ich hatte den Eindruck, dass das reine wifi lock irgendwann von selbst wieder weggeht (nach einigen Minuten), wenn man nicht durch weitere Aufrufe weiter reinfeuert.
Nach der Argumentation würde dann aber die Essenz aus Tims Patch reichen, weil wenn sich wifi fängt, läuft das ursprüngliche configurehood "irgendwann" durch.

> 
> > Gibt es für sowas in Linux Mechanismen? Primitiv könnte man natürlich
> einfach
> > per micrond zwei Minuten später den Prozess killen, aber vll. gibt es für sowas
> > was elegantes? Vll. gibt es auch etwas, was nicht nur einfach von der Zeit
> > abhängt?
> 
> timeout(1) kann sowas, ist aber nicht in der Firmware.

Das schaue ich mir mal an. Schön ist das aber in jedem Fall nicht.

Ich wäre dafür, den Patch ohne Entfernen von /tmp/started mal einzuspielen.
Ich kann aber leider den Code nicht selbst reviewen, du hattest aber ja nachvollzogen, dass er funktioniert?

Grüße

Adrian

> 
> Gruß
> Fabian