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

[mail at adrianschmutzler.de]

Hallo Tim,

> -----Original Message-----
> From: Tim Niemeyer [mailto:tim at tn-x.org]
> Sent: Samstag, 20. Januar 2018 16:43
> To: mail 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 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.

Dann mach bitte du oder jemand anderes so eine Lösung. Ich kann das nicht. Und wenn könnte ich nicht beurteilen, ob das eine gute Lösung ist. Im Moment kommt mir das umständlich vor, weil ...

... ich kann sehr gut mit dem alfred restart im configurehood leben. Und ich finde es einfach und elegant.

Und solange niemand außer uns beiden darüber diskutiert und das hier liest, werden wir diese Sache wahrscheinlich auch nicht weiter bringen.

> 
> > 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.

Das ist der ausschlaggebende Punkt von rc.local nach S98 zu verschieben.

> 
> > 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.

Ja. Ist aber bash. Haben wir das? Mir ist es Rille, ob man das so oder so macht...

> 
> > 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.

Alfred startet mit meinem restart Patch dann schon noch. Das funktioniert super. Aber da werden wir uns wohl nicht einigen.

> 
> 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!

Deshalb mag ich meine Lösung, die ist so schön einfach.

Grüße

Adrian

> 
> Tim
> >
> > Beste Grüße
> >
> > Adrian
> >
> > >
> > > Tim
> > >
> > > > +
> > > > +start()
> > > > +{
> > > > > > > +	sleep 3
> > > > > > > +	/usr/sbin/configurehood
> > > > +}
> > > > --
> > > > 2.7.4
> > > >
> >
> >