Ok, da kann man jetzt geteilter Meinung sein
Eigentlich ist das Double Forking ursprünglich zur Daemonisierung von Prozessen gedacht.
Es ist NICHT dazu gedacht Prozesse aus einer Shellumgebung in den Background zu schieben.
Schneidest du im system.exec() dann eigentlich hinten das "&" ab oder gibst du das auch noch mit in den Double Fork? Also Fork,Fork,BackgroundProcessGroup? Ich nehme das jetzt mal für meine weiteren Überlegungen so an - solange du nicht das Gegenteil sagst.
Habe ich gerade probiert - seit dem ist die Haupt ReGa auch tot, zusammen mit der WebUI.Und weitere system.Exec() könntest du doch via der "Skript testen" Funktion testen oder blockiert das auch bereits?!? Und was ist wenn das passiert? Läuft dann das wget des pocketcontrol aufrufes noch? In meinen tests konnte ich nämlcih selbst ein "sleep X" aufrufen im system.Exec() mit sehr langer zeit und trotzdem kann ich dann weitere system.Exec() aufrufen
Ich habe einfach das Pushscript von Pocketcontrol genommen und dort einen festen String eingetragen, den er schicken soll. Anders hätte ich nämlich nicht so einfach prüfen können ob es geht - bin ja im Büro und habe von hier keinen shell access auf die RM.
Achtung: Wild Guess! : Ich glaube auch, dass mit einem sleep 100 oder so nie Probleme bekommen wirst, ich glaube eher dass extrem kurze Laufzeiten bei deinem double-fork-into-backgroundPG dazu führen, dass der background process des double fork eher abgeschlossen ist, bevor du ihn überhaupt orphanen kannst und die zweite ReGa dann hängt, weil sie kein waitpid() mehr macht, der kernel sie aber auch den background process nicht mehr orphanen lässt, weil er ja schon SIGTERM ist.
Ergibt da Sinn oder habe ich mich unverständlich ausgedrückt?
Ich kann halt leider auch nur wild spekulieren, da ich den Code nicht kenne...