[PATCH] fhemFork signal handling

[justme1968]

hier: https://forum.fhem.de/index.php/topic,41804.msg425231.html#msg425231 ist Hinrichs einem problem auf den grund gegangen bei dem sich herausgestellt hat das es damit zusammen hängt das fhem nach dem fork die signal handler nicht wieder auf default setzt.

der angehängte kleine patch behebt das. ich vermute es könnte im prinzip noch andere signal handler betreffen.

neben dem speedtest modul behebt das eventuell auch noch zwei seltsame probleme in yowsup und im SPEEDTEST modul. vielleicht auch noch an anderen stellen.

unabhängig davon: würdest du einen patch einbauen bei dem fhemFork einen optionalen parameter bekommt über den mit socketpair stdin und stdout zum child gleich so konfiguriert werden das parent und child kommunizieren können? ein beispiel gibt es in yowsup und in der neuen SPEEDTEST version. wenn ich endlich dazu komme die sanbox fertig zu bauen wäre es da auch nützlich und boris SubProcess.pm wäre eventuell auch ein kandidat der es nutzen würde.

gruss
  andre

Code Auswählen Erweitern

--- fhem.pl (revision 11071)
+++ fhem.pl (working copy)
@@ -4482,6 +4482,10 @@
       DevIo_CloseDev($h,1);
     }
   }
+
+  # restore default behaviour
+  $SIG{CHLD} = 'DEFAULT';   
+
   return 0;
}


[rudolfkoenig]

Habs eingecheckt, da es auch mAn theoretisch der richtige Weg ist.
Bin auf Nebeneffekte (aka Zombies) gespannt.

[justme1968]

sehr schön.

und die zweite frage ?

[rudolfkoenig]

und die zweite frage (https://forum.fhem.de/Smileys/default/smiley.gif) ?

Die habe ich gestern abend gelesen, und heute vergessen
Ja, wenn es portabel (Stichwort Windows) ist. BlockingCall waere auch ein Kandidat.

[Markus Bloch]

Hallo zusammen,

ich habe hier https://forum.fhem.de/index.php/topic,53356.0.html 2 User, welche aufgrund dieses Patches nun Zombie-Prozesse beim Start von FHEM haben.

Man muss dazu sagen, dass die Installation mit >400 Definitionen auch durchaus enorm groß ist. Beim Start von FHEM scheint mir der Fall einzutreten, dass die Hardware nicht genug Performance hat um ca 17 BlockingCalls zeitnah zu bearbeiten und dann aufgrund des Standardverhaltens im SIGCHLD als Zombies verweilen.

Ich habe auf anraten von Rudi bereits im Rahmen von https://sourceforge.net/p/fhem/code/11463/ $SIG{CHLD} innerhalb des Blocking-Call wieder auf 'IGNORE' gesetzt. Aber das Ergebnis bleibt gleich.

Hat jemand eine Idee, wie man die Zombies noch verhindern kann?

Vielen Dank

Gruß
Markus

[rudolfkoenig]

Koennt ihr bitte testen, ob wirklich dieser Patch dran Schuld ist?
Mein Vorschlag mit $SIG{CHLD} = 'IGNORE' sollte eigentlich die Auswirkung dieser Patch neutralisieren.