Programme werden nicht mehr ausgeführt

[jmaus]

So, ich denke ich habe das Problem gefunden und beseitigt das Bulli hier mit Testcase demonstriert hatte (danke noch einmal dafür!) bei dem es mit zwei Sekundentimer basierten aufrufen von system.Exec() mit '&' dazu kam, das ein Regaprozess nicht aufgeräumt wurde und daher die weitere Abarbeitung von Programmen oder weiteren system.Exec() Aufrufen nicht mehr funktioniert hatten. Mit der nächsten ReGa Version (die eQ3 erst noch freigeben muss) sollte das Problem also hoffentlich behoben sein.

[homie_]

Applaus! Applaus !

[srunschke]

So, ich denke ich habe das Problem gefunden und beseitigt das Bulli hier mit Testcase demonstriert hatte (danke noch einmal dafür!) bei dem es mit zwei Sekundentimer basierten aufrufen von system.Exec() mit '&' dazu kam, das ein Regaprozess nicht aufgeräumt wurde und daher die weitere Abarbeitung von Programmen oder weiteren system.Exec() Aufrufen nicht mehr funktioniert hatten. Mit der nächsten ReGa Version (die eQ3 erst noch freigeben muss) sollte das Problem also hoffentlich behoben sein.

Hallo Jens,

kannst du sagen was der eigentliche Fehler war?
Mich würde einfach interessieren, ob ich mit meiner unten stehenden Vermutung damals zumindest nah dran war am Problem.

S

In der Tat sollten die die das problem haben mal probieren das "&" im PC Push skript wegzulassen. Meine vermutung ist allerdings das das nichts bringen wird und die ReGa dann lediglich für die gesamte Ausführungszeit des wget blockiert wird. Es sollte also in der tat genau anders herum sein und mit einem "&" ReGa auf andere Anfragen reagieren und eben Programme und vo besser ausführen.

Das Problem ist aber meiner Meinung nach nicht das wget. Wäre es so, dann wäre ja auch das wget der Zombie. Es ist aber der Shell Prozess, der für das wget geforked wird. Dafür forked die ReGa sich scheinbar vorher selber, um den Prozess von sich zu isolieren - damit genau das eigentlich nicht passiert. Funktioniert nur scheinbar nicht so gut.

Für mich sieht das so aus, dass die zweite ReGa den wait() auf den sh Fork nicht sauber verarbeitet und daher den SIGTERM irgendwie verpasst - dann kommt es zum Zombie und die zweite ReGa wird deshalb nie beendet.
Daher gilt es meiner Meinung nach heraus zu finden: warum bekommt die ReGa nicht mit, dass der sh Prozess sich beendet?

Als Dirty-Workaround könnte man auch einfach den Fork und das wait() mit SIG_IGN flaggen - wenn die ReGa sich eh nicht für die Returncode Verarbeitung interessiert. Damit würden sich dann auch die Zombies erledigen. Aber ob das der Weisheit letzter Schluss ist? Damit enthebt man die ReGa nämlich auch von der Möglichkeit jemals Returncodes von System.exec() sauber zu verarbeiten.

[jmaus]

kannst du sagen was der eigentliche Fehler war?
Mich würde einfach interessieren, ob ich mit meiner unten stehenden Vermutung damals zumindest nah dran war am Problem.

Ja, ich kann probieren es zu beschreiben. Das Problem qar in der Tat nicht das wget oder der geforkte sh aufruf. Das Problem war in der ReGa an ganz anderer Stelle vergraben. Und zwar bei der Verarbeitung des zweiten ReGa fork() und wie Subprozesse innerhalb der ReGa aufgeräumt werden/wurden. Hier gab es das Problem das in dem Falle von system.Exec() mit einem & es zu dem Problem kommen konnte, das der temporäre 2. ReGa Prozess nicht korrekt beendet werden konnte und deshalb auch nicht entsprechend aufgeräumt wurde. Als folge dessen kam es dann dazu, das eben weitere Subprozesse nicht mehr gestartet werden konnten. Im Engeren Sinne hatte das also nichts mit dem double forking zu tun denn da war alles korrekt umgesetzt. Jedoch brachte das double forking das gerade beschriebene falsche Verhalten zum vorschein.

Danke daher noch einmal an alle die mitgeholfen haben das Problem zu Tage zu fördern und vor allem Bulli für den guten Testcase der es mir erst ermöglichte in reproduzierender Weise das Problem zu finden und zu eliminieren.

[Andy1204]

Danke für dein Statement
Hälst du uns auf dem laufenden wann es in der neuen FW behoben ist / wurde ?

[jmaus]

Sollte dann im ChangeLog von RaspberryMatic erkenntlich sein sobald eine neue Version draussen ist.

[srunschke]

Ja, ich kann probieren es zu beschreiben. Das Problem qar in der Tat nicht das wget oder der geforkte sh aufruf. Das Problem war in der ReGa an ganz anderer Stelle vergraben. Und zwar bei der Verarbeitung des zweiten ReGa fork() und wie Subprozesse innerhalb der ReGa aufgeräumt werden/wurden. Hier gab es das Problem das in dem Falle von system.Exec() mit einem & es zu dem Problem kommen konnte, das der temporäre 2. ReGa Prozess nicht korrekt beendet werden konnte und deshalb auch nicht entsprechend aufgeräumt wurde. Als folge dessen kam es dann dazu, das eben weitere Subprozesse nicht mehr gestartet werden konnten. Im Engeren Sinne hatte das also nichts mit dem double forking zu tun denn da war alles korrekt umgesetzt. Jedoch brachte das double forking das gerade beschriebene falsche Verhalten zum vorschein.

Danke daher noch einmal an alle die mitgeholfen haben das Problem zu Tage zu fördern und vor allem Bulli für den guten Testcase der es mir erst ermöglichte in reproduzierender Weise das Problem zu finden und zu eliminieren.

Vielen Dank für die Erklärung und deine Arbeit!

[Hypnos]

Hallo,

Bei mir läuft es die letzten Wochen auch stabil (den ganzen Urlaub kein Problem).

Das System.exec nutzte ich mir dem & recht viel. Habe aber vor ein paar Wochen eine Reihe Programme auf RedMatic migriert.

Darunter zufälligerweise diejenigen, welche das System.exec intensiv eingesetzt haben (Push Nachrichten, etc.).

Damit deckt sich das mit dem hier gefundenem.

Danke für die Mühen!

[Anders]

Jetzt wo ich ich hier gelesen ich endlich weiss woher kommen hundreds of zombi processes auf mein vier ccu2. Die problem ist schon lange da so wann wird eq3 die coding fehler von jmaus beheben? Warum es gibt kein announcement oder sticky thread mit warnung vor nutzen background processes in forum?

[Andy1204]

ich hatte/hab zuvor auch alles durch; Programme löschen ; Sensoren Autoren ablernen
reset´s ; diagramme alle rausgeworfen usw .. bis auf leider das push in dem Falle nicht
immerhin gut zu wissen den Fehler jetzt zu haben! und hoffen das er bald gefixt wird