Forkable FHEMWEB Extensions

Begonnen von rudolfkoenig, 12 September 2014, 07:50:59

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

Zitat von: justme1968 am 02 Dezember 2014, 21:03:36
ein block dieser art (aus BlockingCall) gehört nach jedes fork

Danke Andre. Schön ist das nicht, aber ich werde es am Wochenende versuchen.

STDIN, STDOUT und STDERR muss ich also nicht schließen und auch keine neue Session mit setsid eröffnen?

Grüße
Boris

Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

herrmannj

andre is right,

die strophe hilft zusätzlich (besser STDOUT und co nach null) .

Das shutdown restart thema hatte ich auch, die hat sich aber schlussendlich erledigt weil ich zwischen papa und kind einen tcp aufmache (den telnet hack mag i net, pipe wäre nur linux). Damit bekommt kind sicher ein tcpclose wenn papa, egal aus welchen gründen auch immer, stirbt. Das catche ich und lass das kind durch clean exit gehen. Vom vorgehen ist das nicht wesentlich aufwendiger als die Telnet Geschichte aber deutlicher komfortabler.  Unter diesen Umsänden spart man sich auch das schließen der anderen handles, zumal man ohnehin nur die erwischt die an bekannten Stellen (in der $def) liegen.

Gegen das problem mit dem fork aus define hilft es nix.

vg
jörg

justme1968

du hast recht. um es ganz sauber zu machen sollte man STDIN,STDOUT und STDERR auch behandeln. einfach nur schliessen ist aber falsch. es gibt geforkte programme die hier gültige handles erwarten.

socketpair bietet sich an. das gibt es unter windows und unix. und es geht auch in beide richtungen. in dem sandbox.pm modul an dem ich arbeite mache ich es so.

das schliessen der handles ist nicht nur für den restart sondern verhindert auch probleme wenn der child prozess aus irgendeinem grund und die fhem select loop gerät oder selber eine select loop verwenden will. d.h. das schliessen spart man nicht wirklich wenn es sauber sein soll.

gruss
andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

ja genau. socketpair dachte ich nur unter unix.

select im chield ist übrigens kein problem, darf nur nicht mit den werten aus %defs gefüttert werden. Wichtig ist da natürlich das koreekte nonblock setup, das muss nach einem accept neu gemacht werden.

vg
jörg

justme1968

socketpair geht auch unter windows. http://perldoc.perl.org/perlport.html#socketpair. das zu emulierten ist aber im gegensatz zu fork auch kein problem.


ein eigenes select nur auf die eigenen fds ist kein problem. wenn man aber in der fhem event loop landet oder in irgendeinem anderen code teil das noch fds aus dem parent verwendet geht es schief. dblog ist unter umständen so ein kandidat.

autoflush ist nicht nur nach accept sondern auch nach dup nötig. lieber ein mal zu viel als zu wenig :)

gruss
  andre


hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

Hallo,

ich habe mich heute morgen daran gemacht, das RSS-Modul weiter aufzubohren. Ich bin zu dem Ergebnis gekommen, dass es sich bei dieser Vorgehensweise um einen Irrweg handelt. Die Komplexität steigt dadurch dermaßen an, dass ich nicht mehr nachvollziehen kann, was abläuft.

Ich darf natürlich nicht alle Handles im Kind schließen, weil ich dann nämlich auch nicht mehr im Kind die von RSS generierte HTML-Ergebnisdatei über die Verbindung vom HTTP-Client zu FHEMWEB zurückliefern kann. Komischerweise funktioniert das aber doch, während der in der HTML-Ergebnisdatei eingebettete IMG-Link zum vom RSS generierten Bild aber nicht bedient wird.

Ferner kann ich nicht mehr loggen und muss mein eigenes Log mitführen, dass ich dann über Callback an den Elterprozess füttere. Das führt zu einem eval im Elternprozess auf Log3(foo, 3, EscapeOrgie).

Und warum ich aus dem Kindprozess heraus überhaupt wieder in die globale select-Schleife komme, verstehe ich schon gar nicht.

Fazit: ich fahre jetzt nicht mehr weiter in diese Sackgasse.

Ich komme wieder auf die parallel laufende API-Diskussion zurück. Eine mögliche Lösung könnte so aussehen, dass FHEM sowohl FHEMWEB als auch RSS nach Definition per exec-Call in separate Prozesse schickt, die sich per API mit FHEM unterhalten.

Viele Grüße
Boris


Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

herrmannj

Hallo,

ZitatFerner kann ich nicht mehr loggen und muss mein eigenes Log mitführen, dass ich dann über Callback an den Elterprozess füttere. Das führt zu einem eval im Elternprozess auf Log3(foo, 3, EscapeOrgie).
Ich glaub das ist gefährlich. Wenn der fork das log3 des papas aufruft macht er das asynchron. fhem-papa steht zu dem Zeitpunkt ja irgendwo.
ZitatUnd warum ich aus dem Kindprozess heraus überhaupt wieder in die globale select-Schleife komme, verstehe ich schon gar nicht.
Hat vielleicht eine Verbindung zu dem noch offenen Thema "forken aus define". Dürfte eigentlich nicht passieren wenn child mit posix::_exit endet, oder geht der dann noch mal in den Hauptprozess ? Dann müssten doch aber nach exit immer noch 2 pids existieren ?
ZitatIch komme wieder auf die parallel laufende API-Diskussion zurück. Eine mögliche Lösung könnte so aussehen, dass FHEM sowohl FHEMWEB als auch RSS nach Definition per exec-Call in separate Prozesse schickt, die sich per API mit FHEM unterhalten.
Würden sie doch auch asynchron machen, regen und traufe ?

vg
jörg

Dr. Boris Neubert

Zitat von: herrmannj am 07 Dezember 2014, 13:30:52
Ich glaub das ist gefährlich. Wenn der fork das log3 des papas aufruft macht er das asynchron. fhem-papa steht zu dem Zeitpunkt ja irgendwo.

Das kommt noch erschwerend dazu. Noch ein Grund mehr, diesen Weg aufzugeben.

Zitat
Hat vielleicht eine Verbindung zu dem noch offenen Thema "forken aus define". Dürfte eigentlich nicht passieren wenn child mit posix::_exit endet, oder geht der dann noch mal in den Hauptprozess ? Dann müssten doch aber nach exit immer noch 2 pids existieren ?

FHEMWEB beendet das Kind mit exit (Zeile 434). Ich sage ja, es ist für mich nicht nachvollziehbar, warum diese Nebenläufigkeit entsteht. Selbst wenn ich es verstehen würde, wäre das ganze Konstrukt so fragil, dass ich es nicht in FHEM haben möchte.

Zitat
Würden sie doch auch asynchron machen, regen und traufe ?

Nicht, wenn das API als Device regulär läuft.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

herrmannj

ZitatDas kommt noch erschwerend dazu. Noch ein Grund mehr, diesen Weg aufzugeben.
Naja, hatte das gleiche Problem  :) Wollte nicht aus dem kind ins log schreiben und lass papa am das auch am socket machen. Die eval orgie hatte (was auch immer Du damit meinst) hatte ich nicht. Kind schickt dem papa einen über den gemeinsamen socket ein cmd (log, mit Kindname, loglevel und Text) und papa schreibt das weg. 
ZitatFHEMWEB beendet das Kind mit exit (Zeile 434). Ich sage ja, es ist für mich nicht nachvollziehbar, warum diese Nebenläufigkeit entsteht. Selbst wenn ich es verstehen würde, wäre das ganze Konstrukt so fragil, dass ich es nicht in FHEM haben möchte.
Yepp!. Ist aber auch ein Zeichen für ein Missverständnis irgendwo. Wie stellst Du die Nebenläufigkeit eigentlich fest? Ich sehe nach einem child exit keine zweite pid mehr ...

vg
jörg

Dr. Boris Neubert

Zitat von: herrmannj am 07 Dezember 2014, 14:01:17
Naja, hatte das gleiche Problem  :) Wollte nicht aus dem kind ins log schreiben und lass papa am das auch am socket machen. Die eval orgie hatte (was auch immer Du damit meinst) hatte ich nicht. Kind schickt dem papa einen über den gemeinsamen socket ein cmd (log, mit Kindname, loglevel und Text) und papa schreibt das weg. 

Mit EscapeOrgie meinte ich, dass ich im Text, den ich mit { Log3 FrameRSS,2,"Text" } an den TelnetPort von Papa sende, alle Sonderzeichen maskieren muss.

Zitat
Yepp!. Ist aber auch ein Zeichen für ein Missverständnis irgendwo. Wie stellst Du die Nebenläufigkeit eigentlich fest? Ich sehe nach einem child exit keine zweite pid mehr ...

Ich sehe nach einer gewissen Zeit, dass mein CUL den Puffer voll hat (ein zeitgesteuertes Kommando wird aus allen Instanzen von FHEM an den CUL geschickt) und dass ich zig Mal dieselbe Mail geschickt bekomme (zeitgesteuerter Shell-Aufruf, mir die externe IP-Adresse meines Routers zu mailen).

Ich habe keine Ahnung, wie ich das schaffe.

Viele Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

herrmannj

tricky und als Indizienbeweis zugelassen  :)

Mit folgendem construct hab ich gerade getestet (würde mich auch massiv betreffen, ANGST  :o )

(fhem.pl, line #551)

print "in select $$ ooo\n";
my $nfound = select($rout=$rin, $wout=$win, $eout=$ein, $timeout);
print "out select $$ +++\n";


Kann das zum Glück nicht bestätigen, ich seh nur den Papa. (aufatme)

vg
jörg