Blocking.pm - laufender Fork verhindert ein "shutdown restart"-Neustart

justme1968 · 24 März 2013, 17:03:21

die patches aus den beiden threads sind unabhängig und haben nichts mit einander zu tun. es ist nur deshalb die gleiche gegend weil ich beim suchen früher gestolpert bin.

gruss
andre

rudolfkoenig · 24 März 2013, 17:48:19

> das diverse server ports nach dem fork nicht geschlossen werden ist ein prinzipieller fehler der behoben werden sollte.

Sehe ich anders: bitte client==Kind und server==Hauptprozess nicht verwechseln.
Das Client liest von keinem dieser Ports/FDs, insofern stoert es nicht. Selectlist spielt nur im Server ein Rolle, und nur dann, wenn das Lesen vom Client uebernommen werden soll.

justme1968 · 24 März 2013, 18:22:22

ich verwechsle sicher nichts und mir ist der unterschied zwischen parent/child und client/server sehr geläufig.

gerade deshalb sehe ich das hier ein problem schlummert das immer wieder zum vorschein kommen wird wenn die verwendungszwecke für das BlockingCall komplexer werden. erst recht wenn nicht dokumentiert ist was ein child prozess darf und was nicht und es für diese einschränkungen keinen wirklich zwingend grund gibt. auch gibt es prinzipiell keine harte 1:1 zuordnung sondern ein child prozess von fhem kann durch aus server für weitere eigene child prozesse sein und nur gegenüber fhem weiter client.

es sind zwei probleme die miteinander zu tun haben weil beide am ende über den gleichen mechanismus (filedescriptoren) ressourcen blockieren und die korrekte lösung die gleiche ist: alle nicht benötigten filedescriptoren sind zu schließen und damit die ressourcen freizugeben.

zum einen die offenen ports: es ist richtig das diese erst mal keine probleme machen weil der child prozess nicht davon liest. es ist aber trotzdem unsauber sie offen zu lassen. und die probleme beim shutdown restart sind doch genau der beweis dafür. wenn sie geschlossen werden gibt es diese probleme nicht mehr! die child prozesse zu beenden wenn der parent prozess beendet wird ist richtig und nötig, hilft aber nur so lange alles sauber läuft. es hilft weder wenn der parent abstürzt noch wenn der child prozess z.b. in einem blockierenden lesen über nfs fest steckt.

zum anderen die offen filedescriptoren: auch hier ist es richtig das die erst mal keine probleme machen so lange der child prozess nicht von ihnen liest. aber es gibt sehr viele anwendungsfälle wo ein child prozess sinnvoller weise mehr machen könnte als nur warten und einen wert zurzeck zu geben und dabei ist das select absichtlich oder nebenbei aufgerufen sehr wohl ein thema.

vielleicht übersehe ich etwas aber es ist für mich völlig unverständlich warum so hartnäckig an offensichtlich falschem verhalten festgehalten wird das keinerlei vorteile bringt sondern statt dessen unter allen möglichen randbedingungen probleme verursachen kann und es auch tut. der patch ist 5 zeilen lang und schafft das problem (und alle damit in zusammenhang stehenden) ein für alle mal aus der welt.

ich denke es ist wichtig defensiv zu programmieren und mögliche fehlerquellen von vornherein auszuschliessen. erst recht wenn das mit so geringem aufwand möglich ist.

rudolfkoenig · 24 März 2013, 18:38:11

> für mich völlig unverständlich warum ...

Weil der Patch keinen mir bekannten Problem loest. Wenn das child weiterlebt, waehrend das parent weg ist, dann finde ich sollte fhem lieber nicht gestartet werden koennen.

justme1968 · 24 März 2013, 19:05:28

in dem fall nicht zu starten ist ein verhalten das sicher sinnvoll ist. aber das sollte nicht nebenbei über den seiteneffekt eines unsauberen verhaltens erreicht werden.

ressourcen nicht freizugeben ist nicht korrekt und es wird wieder zu problemen führen. es ging mir nicht nur darum ein problem zu lösen sondern problemen vorzubeugen.

aber es ist dein projekt und deine entscheidung welche fehler drin bleiben.

nur weil ich bis jetzt jedes mal zu faul war meinem verdacht nach zu gehen und selber nach zu schauen hab ich bis jetzt nicht gesagt: 'ich hab es ja gleich gesagt'. beim nächsten mal darf ich es aber dann.

vielleicht sollte man im Blockig.pm dokumentieren was erlaubt ist: nur blockieren und antworten zurück geben und was nicht: z.b. kein TcpServer_Open und eigene main loop, keine devices schalten , ...

justme1968 · 25 März 2013, 15:41:28

mit dem offiziellen stand von heute ist es in meiner installation nicht möglich fhem zuverlässig mit shutdown restart neu zu starten.

von 10 versuchen ist genau einer erfolgreich durchgelaufen. alle anderen 9 bleiben reproduzierbar mit

Code Auswählen

2013.03.25 15:21:45 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting. beteiligt sind nur eine handvoll presence pings.

scheinbar werden die geforkten child prozesse nicht zuverlässig und/oder schnell genug beendet.

mit meinem patch der die offenen ports schließt tritt das problem nicht auf. ein shutdown restart funktioniert problemlos in 10 von 10 fällen.

wenn aber das korrekte handling der sever ports keine alternative ist wäre es schön wenn wenigstens die bevorzugte methode zuverlässig funktionieren würde.

gruss
andre

ps: sich auf den belegten port zu verlassen um einen mehrfach start zu verhindern funktioniert ziemlich sicher unter windows überhaupt nicht.

justme1968 · 25 März 2013, 15:41:42

doppelt gepostet...

Markus Bloch · 25 März 2013, 17:28:04

Hallo Andre,

leider ist diese Funktion noch nicht in Presence übernommen worden. Da ich aktuell unterwegs bin, wird es noch 2 wochen dauern bevor ich das einbringen kann. Testen kann ich aus der Ferne nicht zu 100%. ;-)

Viele Grüße

Markus

justme1968 · 25 März 2013, 17:37:55

hallo markus,

das sollte kein vorwurf sein und schon gar nicht an dich.

ich bin der meinung der richtige umgang mit systemfunktionen und das korrekte beenden gehört in die infrastruktur die fhem liefert und ist nichts etwas das in jedem einzelnen modul extra eingebaut werden muß damit es geht. erst recht weil die richtige korrekte und nebenwirkungsfreie lösung 5 zeilen code an einer zentralen stelle sind die das problem ein für alle mal beheben.

ein server der durch module erweiterbar ist sollte so defensiv programmiert sein das er nicht darauf angewiesen ist das diese module nicht nur alles richtig machen sondern sogar probleme für die sie garnichts können ausbügeln.

gruss
andre

rudolfkoenig · 26 März 2013, 10:03:15

> aber es ist dein projekt und deine entscheidung welche fehler drin bleiben.

Soviel darueber.

Ich habe den Patch eingecheckt, weil ich keine Lust auf weitere Diskussionen habe, zu meiner Meinung stehe ich immer noch. Bitte beachten:

- wenn der Kindprozess im UndefFn nicht abgeschossen wird, dann wartet er weiterhin auf Daten, und der nach dem fhem-restart aufgerufene zweite BlockingCall wird vermutlich Probleme bekommen.
- es werden nicht nur telnet-ports, sondern alle TCP Server Ports (FHEMWEB/FRM) geschlossen
- mit BlockingCall kann man ab jetzt keine Serverports mehr bedienen
- alle anderen FDs sind weiterhin offen

Gruss,
Rudi

Markus Bloch · 26 März 2013, 10:26:40

Hallo Rudi,

nur kurz zum Verständnis für mich, da ich bei eurer Diskussion nicht ganz mitgekommen bin.

Für PRESENCE müsste ich in der UndefFn sämtliche noch laufenden Childs via BlockingKill und der gespeicherten ProzessId nieder mähen?

Oder hab ich noch was übersehen?

Vielen Dank
Gruß

Markus

rudolfkoenig · 26 März 2013, 10:34:10

> Für PRESENCE müsste ich in der UndefFn sämtliche noch laufenden Childs via BlockingKill und der gespeicherten ProzessId nieder mähen?

Ja, immer. Egal ob mit oder ohne Patch.
Wenn das schwierig ist, koennte man ueberlegen das in fhem global zu verwalten.

Markus Bloch · 26 März 2013, 10:59:32

Nein, nein. Schwierig ist das nicht ;-)

Ging nur darum ob ich das so richtig interpretiert habe aus eurer Diskussion.

Viele Grüße

Markus

justme1968 · 26 März 2013, 12:07:42

danke! ganz wirklich und ohne ironie.

eine anmerkungen noch: natuerlich kann man in einem blocking call server ports bedienen. entweder im child auf machen und nicht im parent das geht jetzt direkt oder nach dem accept im child genau dieses eine socket offen lassen und es statt dessen im parent schließen. beides ist sauber weil nie beide das gleiche socket offen habe. ich baue den patch gerne um wenn es bedarf dafür gibt.