HomeMatic-Forum / FHZ-Forum

jmaus hat geschrieben: ↑

27.07.2018, 03:02

Doch genau dafür ist das double forking da.

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.

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

Habe ich gerade probiert - seit dem ist die Haupt ReGa auch tot, zusammen mit der WebUI.
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...

Nur noch mal für mich als Noob... Ist das nun das gleiche Problem was ich auch hab oder nicht? Bei mir ist nach der Push Meldung Schicht im Schat. Was mich irritiert, ich hab bzgl. Aquariumzeug andere Push Meldungen am laufen, da kamen heute zwei und nix ist weiter passiert komisch.... hab eben wieder eine Push Nachricht Zeit gesteuert ausgelöst und siehe da, hängt wieder

verstehe nur Bahnhof! hoffe Ihr bohrt da weiter und findet den Übeltäter.
Zwischen-Info von mir: seit das HMIP-PSM Gerät nicht mehr angemeldet ist, tritt der Fehler deutlich seltener auf!

Hallo zusammen,
auch ich verfolge diesen Thread mit Aufmerksamkeit, da ich selber betroffen war:
hatte das Phänomen, das z.B. der HM-PB-6-WM55 (Tasten waren verknüpft mit Programmen) seinen Befehl ohne Fehlermeldung abgesetzt hatte, das/die Programm(e) aber nicht gestartet wurde...
Automatische Rollo-Steuerung nach Astro-Zeit: keine Reaktion...
pocketControl-Push-Nachrichten: nix mehr
Im Einsatz habe ich nen Raspberry 3B+ (altes Funkmodul) mit aktueller Raspberry-Matic 2.35.16.20180715
Keine HM-IP Komponenten, keine Homematic Wired Komponenten...
Nach dem gefühlt x-ten Neustart lief mein System nunmehr fehlerfrei seit ca. 1,5 Wochen.
Wenn ich helfen kann, gerne...

Ich habe das gleiche Problem, ich habe das PC Skript mit dem & wie hier beschrieben wurde angepasst ; bisher läuft es stabil durch.
Tendenziell würde ich auch sagen das es ein zusammenhang gibt mit den pushnachrichten; IP Komponenten hab ich 3 Bewegungsmelder - die hänger hatte ich aber auch meines wissens vorher.

Ansosten äussert sich das eben genau so wie bei allen anderen- Programme werden nicht mehr gestartet; befehle gehen aber raus

Fratzke hat geschrieben: ↑

28.07.2018, 19:07

Nur noch mal für mich als Noob... Ist das nun das gleiche Problem was ich auch hab oder nicht? Bei mir ist nach der Push Meldung Schicht im Schat. Was mich irritiert, ich hab bzgl. Aquariumzeug andere Push Meldungen am laufen, da kamen heute zwei und nix ist weiter passiert komisch.... hab eben wieder eine Push Nachricht Zeit gesteuert ausgelöst und siehe da, hängt wieder

Sagen wir mal so: ich gehe stark davon aus, dass die Ursache die Gleiche ist.

Was ich rausgefunden habe:
- ich kann Pushnachrichten ohne Ende schicken und die RM läuft weiter, aber wenn ich sie in Zusammenhang mit einem Programmgewusel aus "Leave Home" + "Alarmanlage scharfschalten" nutze, dann hängt sie sich manchmal auf. Manchmal sogar schon direkt nach dem Reboot, wenn das Pushscript aktiviert wird durch den Reboot.
- Wenn sich die RM aufhängt, dann wurde die Shell nicht durch den double-fork der ReGa in den Hintergrund geschoben, ansonsten klappt das scheinbar immer

Mutmaßungen:

1. Es besteht ein Zusammenhang aus parallel gestarteten Programmen, die durch den gleichen Trigger ausgelöst werden, oder die innerhalb des Programmes weitere Trigger auslösen, die andere Programme starten.
2. Es besteht ein Zusammenhang mit Programmen die "ausführen in X minuten" enthalten

Ich versuche zeitnah mal ein Testszenario zu generieren, damit Jens das bei sich nachbauen kann.

Alle betroffenen könnten auch bitte einfach mal aus dem PocketControl Push Notification Programm das "&" am Ende des system.Exec() Aufrufes entfernen und dann über einen längeren Ueitraum schauen ob damit das Problem behoben ist. Wenn ja deutet das in der Tat noch auf irgendwelche Probleme mit dem doible forking mechanismus hin der bei der Nutzung des "&" am Ende verwendet wird.

das habe ich gemacht - bisher läuft es seit ca 6 Tagen mit täglich min 1-2 Push durch
auch Programme hatte ich in der zeit noch bearbeiten können ohne das sich was weghängt; ich werde in ca 1-2 Wochen wenn es stabil läuft (wäre neuer Rekord dann) wieder mich hier melden

Ich glaube, dass ich gerade einen Blackout habe - kann mir jemand sagen, wo ich das PocketControlScript finde, damit ich es ändern kann.
Danke und Grüße Georg

unter programme
und dann systeminterne auch einblenden