[PATCH v3 2/3] init.d/fff-hoods: Move call of configurehood to init.d script

[Tim Niemeyer]

Hi

Am Samstag, den 20.01.2018, 16:26 +0100 schrieb mail at adrianschmutzler.de:
> Hallo Tim,
> 
> > -----Original Message-----
> > > > From: Tim Niemeyer [mailto:tim at tn-x.org]
> > Sent: Samstag, 20. Januar 2018 15:46
> > > > To: Adrian Schmutzler <freifunk at adrianschmutzler.de>; franken-
> > dev at freifunk.net
> > Subject: Re: [PATCH v3 2/3] init.d/fff-hoods: Move call of configurehood to
> > init.d script
> > 
> > Hi
> > 
> > Am Freitag, den 05.01.2018, 00:52 +0100 schrieb Adrian Schmutzler:
> > > This ensures that configurehood is executed AFTER the LEDS are set up,
> > > but BEFORE alfred.
> > 
> > Wir hatten ja vorhin schon festgestellt, dass das nicht nötig ist, weil wir ja br-
> > mesh eh dauerhaft da haben wollen.
> 
> Im Moment hat _niemand_ den Hauch einer Idee, wie wir br-mesh
> zwingen, da zu sein.
Nochmal: Mit einem Dummy-Interface geht es garantiert! Vielleicht
bietet aber sogar openWrt bereits mit force_link=true eine eigene
Lösung von Haus aus. Muss man sich angucken.

> Ich selbst habe mich sehr lange damit auseinandergesetzt, dass
> Problem einzuengen.
> Mit und ohne diesen Patch wird configurehood VOR alfred ausgeführt,
> also ist es insofern egal.
> Der Unterschied ist, dass mit diesem Patch die LEDS (S96...) schon
> richtig an sind, wenn das configurehood wegen des random ewig
> braucht.
Achso.. Hm. Na die LED's sind mir irgendwie total egal!

Das etwas mal länger dauert ist unschön, sollte aber hier kein
ausschlaggebender Punkt sein.

> Ein Grund, das configurehood nach Alfred zu starten ist mir nicht bekannt.
> 
> > > 
[..]
> Nach den LEDs (96), vor Alfred (99); Begründung siehe oben.
> 97 ginge auch.
> 
> > 
> > Über cron darf das Script erst gestartet werden, wenn /tmp/started angelegt
> > ist, das soll ja aber eigentlich erst nach allem anderen da sein..
> 
> Genau, wenn du also 1/3 nicht magst, den hier aber schon, dann ist
> /tmp/started in der rc.local (S95) und configurehood später und dann
> geht’s kaputt.
Ich mag Patch 1/3, aber ich akzeptiere ihn nur, wenn er mit einem
eigenen Package kommt. Oder wenn ordentlich dargelegt werden kann,
warum man ihn in ein vorhandenes Package legen kann.

> > Ich habe den Verdacht, dass /tmp/started für configurehood gar nicht
> > relevant ist. Oder siehst du da irgendwas, was unbedingt vorher da sein
> > muss?
> 
> /tmp/started steht explizit im cron und hat NUR den simplen Zweck,
> ein gleichzeitiges Ausführen von configurehood durch init.d und cron
> zu verhindern. Das ließ sich so am einfachsten lösen, da man keine
> eigene Datei anlegen muss.
Gut. Dann müssen wir den Mechanismus an der Stelle nur etwas ändern und
es ist sauberer:
https://www.mylinuxplace.com/bash-singleton-process/

Es zeichnet sich für mich gerade ab, dass wir /tmp/started hoffentlich
bald gar nicht mehr brauchen.

> Abschließend: Ich bin solange NICHT der Meinung, dass das br-mesh
> immer an sein muss, bis ich eine Lösung dafür sehe, die sinnvoll ist.
> Im Moment haben wir noch nicht mal eine grobe Idee davon. Deshalb
> weiß ICH auch nicht, ob ich so eine Lösung dann will.
Anders geht es aber nicht, weil sonst das alfred nicht startet.

Ich weiß nicht, ob procd eine Abhängigkeit auf ein Interface
ermöglichen kann. Das wäre eventuell noch eine Möglichkeit das Alfred
sauber zu starten, ohne dass br-mesh immer da ist. Noch eine weitere
Idee wäre ein ifup/down-Script, wo man dann alfred startet/stoppt.

Das führt aber alles dazu, dass man beim Benutzen von Alfred auch
aufpassen muss, ob Alfred überhaupt gerade erreichbar ist!

Tim
> 
> Beste Grüße
> 
> Adrian
> 
> > 
> > Tim
> > 
> > > +
> > > +start()
> > > +{
> > > > > > +	sleep 3
> > > > > > +	/usr/sbin/configurehood
> > > +}
> > > --
> > > 2.7.4
> > > 
> 
> 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180120/f2a8fba1/attachment.sig>