Programme werden nicht mehr ausgeführt

[srunschke]

Wenn die RegaHss nicht mehr läuft, wäre die Aussage:

* WebUI funktioniert

doch *IMHO* so nicht korrekt.

Kannst du das weiter elaborieren?

Mit "WebUI funktioniert" meine ich, dass ich drauf komme und sie bedienen kann.
Programme starten konnte ich dennoch nicht...

Vielleicht hat sich in ReGa auch nur der Teil weggehängt, der "externe" Befehle nutzt, keine Ahnung. Ich habe mich noch nicht tiefer mit der internen Funktionsweise der ReGa beschäftigt.
Wie gesagt, ich konnte auf der Konsole erkennen, dass einer meiner beiden ReGa Prozesse eine Shell geforked hatte und diese dann zum Zombie wurde. Offensichtlich hat die ReGa kein Handling dafür - was imho auch ein Bug ist.

S

[srunschke]

Ein Absturz der RegaHss macht die Klickibuntioberfläche unbedienbar.
Hast du eine geöffnete Browsersession, erscheint zeitnah die Mitteilung diesbezüglich "Eine Komponente reagiert" nicht als weißes PopUp.
Der Versuch eine neue Browsersession aufzumachen endet in blauem Screen "CCU noch nicht bereit"

Das war definitiv nicht der Fall. Die UI ging, lediglich Programme wurden nicht ausgeführt. Interessanterweise hat ReGa den Programmstart in /var/log/messages gelogged und sogar die Parameter sauber erkannt - allerdings ist leider rein gar nichts passiert. Zb wenn ich an meiner HMIP Fernbedienung die Alarmanlage ausschalten wollte - was im Endeffekt ein Trigger auf einen SHORT_PRESS war und ein Programm auslöst, welches eine Systemvariable umstellt. Trigger erkannt, Programm (angeblich) gestartet - nichts passiert.

Bzgl deines Forumtipps, siehe einer meiner vorherigen Posts.

Ich hatte hinterher 3 ReGaHss Prozesse laufen, von deinen einer allerdings jene Zombieshell als Fork hatte und damit wahrscheinlich blockiert war.
Leider konnte mir noch niemand sagen, ob möglich/ok/gut/schlecht ist, wenn mehr als ein ReGaHss Prozess läuft.

Ich überlege gerade, ob ich mir das selber mal anschauen sollte, allerdings mag ich ungerne das Rad neu erfinden, wenn doch vielleicht andere gute Tipps haben, wo ich suchen könnte. Ich würde es ja gerne debuggen, brauche allerdings ein paar Hinweise in die richtige Richtung.

S

[srunschke]

Passiert auch, wenn ein Programm "falsch" ist, und hier der Rat gegeben wird, das Programm zu löschen und genau so wieder anzulegen.
Was auch meistens hilft.

Ja, hatte ich auch schon mal - aber dann betrifft es ja nur das eine Programm. Hier betrifft es alle auf einmal und ein Reboot (oder wie ich jetzt gemerkt habe, auch ein Restart der ReGa) behebt das Problem.

Ich überlege gerade, ob ich mir das selber mal anschauen sollte

Das ist doch ein guter Vorschlag.
Was deine Zombies angeht, da hilft dir die Suche.
Du kannst natürlich auch jmaus direkt anschreiben. Da du dich ja in "seinem" Forenteil befindest, wird er sicherlich schon mitgelesen habe, außerdem war er ja auch hier im Thread schon selber aktiv.
Bugmeldungen nimmt er sicherlich gern entgegen. >> H I E R << wäre vielleicht ein Ansatz. Natürlich steht es dir auch frei, es >> EQ3 per Webformular <<zu melden.

Ich dachte halt ich frag erst mal in der Community rum, bevor ich mit alten Klamotten den Entwickler nerve
Aber leider habe ich jetzt realisiert, dass die ReGa ja closed source ist und nur Jens Zugriff darauf hat. Dementsprechend kann ich da auch nicht wirklich etwas nachschauen und für Glaskugellesen ist mir meine Zeit zu schade...
Mit etwas mehr suchen bin ich aber auf folgenden Beitrag gestoßen: viewtopic.php?p=432478#p432478
Nur dass ich nicht mit Scripten und "&" rumhantiere - Das Verhalten ist absolut identisch zu meinem!

Was mir auch aufgefallen ist - retrospektiv - ist dass die Reaktionen meiner Programme auch immer langsamer werden. Das merke ich halt sehr deutlich an meiner Alarmanlagenfunktion. Habe ich den RM frisch rebooted, dann kommt das Audiofeedback über die Alarmsirene beim (un-)scharf schalten sofort und je länger der RM läuft, des länger dauert es - teilweise dann sogar einige Sekunden bis zum "Doppelpiep" für scharf geschaltet - ultimativ dann irgendwann zum vollständigen Stillstand, der aber jetzt erst zum dritten Mal vorgekommen ist. Ich vermute, dass es dort irgendwelche Zusammenhänge gibt - allerdings ist es unmöglich in die Richtung zu debuggen, wenn der Code closed source ist. Und meine Motivation jetzt 300 empirische Testreihen über 3 Wochen zu fahren ist leider mäßig. Zumal das auch immer mehr zum Abfall des Wife-Acceptance-Factor führen wird, wenn ich soviel mit dem System bastel Wird vielleicht Zeit für ein Testsystem...

S

PS: Aber danke, dass du dich dennoch mit meinem Thema beschäftigst - da fühle ich mich nicht ganz so alleine auf weiter Flur

[srunschke]

Da du bisher überhaupt keine ScriptCodes gepostet hast, kann man natürlich auch nichts daraus ableiten.

Das liegt daran, dass ich - wie schon gesagt - keine Scripte verwende
Wir reden hier rein von plain HM Programmen, wo ich mit Bordmitteln arbeite.

Das "einsame & hinter dem system.exec Aufruf" bringt nach den Infos welche im Forum zu finden sind und vor allem wie ich sie bisher verstanden habe, den Vorteil das dadurch ein ich nenn es mal fire&forget realisiert wird.

Quasi richtig. Im unixoiden Umfeld bedeutet das "&" am Ende eines Befehls, dass das gerade gestartete Programm vom aktuellen Eingabeterminal (meistens eine Shell) entkoppelt und im Hintergrund weiter ausgeführt wird - auch als "Background Fork" bezeichnet.

Unnötiges Wissen am Rande:
- den gleichen Effekt erhält man auch, wenn man ein Programm startet, CTRL-Z drückt und dann "bg" eingibt
- man kann über die Eingabe von "jobs" eine Übersicht aller von dem aktuellen Terminal in den Background geforkten Prozesse erhalten
- mittels "fg PID" (wobei PID der ProcessID des geforkten Prozessen entsprechen muss) kann man einen Prozess aus dem Background wieder in den Foreground holen

Leider hilft mir das gar nicht, da ich das alles nicht nutze im Moment.

Ich werde mal schauen, ob ich meine Theorie mit der falschen IP der Bridge irgendwie bestätigen und das Problem reproduzieren kann.

S

[srunschke]

So, das Problem ist soeben erneut aufgetreten.

Alle Programme sind stehengeblieben, es gibt 2 ReGaHss Prozesse und einen Zombe sh Prozess.
Scheinbar blockieren die beiden Forks die Haupt-ReGa bei der Ausführung der Programme.

Ich werde jetzt mal die IP der HUE Bridge auf die aktuell richtige drehen und schauen, ob das Problem dann wieder reproduziert werden kann.

S

[homie_]

Hallo srunschke,

leider habe ich gerade das gleiche Problem. Habe mir den Raspi B3+ geholt und da natürlich gleich die neueste Firmware 2.31.25.20180428 draufgespielt.
Große Überraschung - alles läuft flott und schick. Lob und Dank an Jens !!!.
Nun habe ich aber das gleiche von Dir beschriebene Phänomen. Nach einem Tag Laufzeit kann man auf die webui Oberfläche - alles anwählbar und veränderbar. Z.B über die pocketcontrol sind alle Systemvariablen einstellbar, Lichter schaltbar (auch Hue) usw. aber alle automatisch startende Programme laufen nicht durch bzw. nicht an. Auch wenn man sie über die Bedienung manuel startet .
Nur den Raspi per shutdown runterfahren und Neustart lässt die HM wieder für ca. einen Tag durchlaufen. Habe meinen Raspi B3 noch mit einem vorherigen Softwarestand und original Speicherkarte - notfalls starte ich den nochmal und schaue ob das Problem nun auch da vorkommt. Zumindest bis zum letzten Tag war mir dieses Problem unbekannt. Auch bei mir gäbe es keinen Sinn ein Programm oder ein script hier reinzustellen denn in diesem Fall laufen alle nicht mehr . Da gäbe es noch mehr Sinn wenn jemand morgen Abend (habe grade neu gestartet) per Fernwartung in mein System schauen würde.

Vielleicht hat doch noch jemand eine Idee ?

Vielen Dank

[srunschke]

Nun habe ich aber das gleiche von Dir beschriebene Phänomen. Nach einem Tag Laufzeit kann man auf die webui Oberfläche - alles anwählbar und veränderbar. Z.B über die pocketcontrol sind alle Systemvariablen einstellbar, Lichter schaltbar (auch Hue) usw. aber alle automatisch startende Programme laufen nicht durch bzw. nicht an. Auch wenn man sie über die Bedienung manuel startet .
Nur den Raspi per shutdown runterfahren und Neustart lässt die HM wieder für ca. einen Tag durchlaufen. Habe meinen Raspi B3 noch mit einem vorherigen Softwarestand und original Speicherkarte - notfalls starte ich den nochmal und schaue ob das Problem nun auch da vorkommt. Zumindest bis zum letzten Tag war mir dieses Problem unbekannt. Auch bei mir gäbe es keinen Sinn ein Programm oder ein script hier reinzustellen denn in diesem Fall laufen alle nicht mehr . Da gäbe es noch mehr Sinn wenn jemand morgen Abend (habe grade neu gestartet) per Fernwartung in mein System schauen würde.

Ideen habe ich leider aktuell keine, aber könntest du mir den Gefallen tun und per ssh auf deine RM gehen und mal nachschauen, ob du auch diesen "sh" Zombie Prozess, sowie zwei laufende Rega Prozesse hast?

S

[homie_]

Hallo,
ich habe mal meine HUE Bridge von einem WLAN Router an einen kabelgebundenen Router angeschlossen und an den Raspi 3B+ einen Kühler montiert - der wurde ganz schön warm. Alles um die Themen die vorher genannt wurden auszuschließen. Sah erst ganz gut aus aber nun ist der Fehler wieder da .
Mein Sohn hat mal auf das System geschaut um Deine Frage beantworten zu können. Hier ein Hardcopy:

ps bei aufgehängter RaspBerryMatic

Es ist bei mir leider auch der SH Zomie zu sehen .

Direkt nach einem Reboot wollte mein Sohn den Raspberry wieder runterfahren mit dem Befehl $poweroff. Komischerweise wurde die ssh Verbindung nicht getrennt, was daran lag, dass der raspi nicht runterfahren wollte.
Bei einem kurzen ps Aufruf fällt sofort wieder das ReGaHss ins Auge.
Es steht da {S70ReGaHss} /bin/sh/ /etc/init.d/S70ReGaHss stop (und das über mehrere Minuten).

raspi_fail_poweroff_ps

Vielleicht schaut ja doch mal Jens da drauf .
Weil sich das Teufelchen vielleicht doch in der ReGaHss versteckt ...
Weitere Info: Das erste Rega mit der PID 913 konnte gekillt werden. Der zweite Rega Prozess mit dem SH Zombie Prozess konnte ich auch nicht mit kill beenden. Nach kill des ersten Prozesses läuft auch die webui nicht mehr.

Ansonsten müsste ich noch mal auf das vorherige Betriebssystem wechseln (das will ich doch eigentlich gar nicht).

[srunschke]

Vielleicht schaut ja doch mal Jens da drauf .
Weil sich das Teufelchen vielleicht doch in der ReGaHss versteckt ...

Ziemlich sicher ist das so - allerdings konnte ich ihn bis jetzt noch nicht dazu bewegen viel zu dem Thema zu sagen.
Ohne wirklichen Zugriff auf den ReGa Code kann ich aber auch nicht wirklich sagen woran es liegen könnte, da ich keine Möglichkeiten habe irgendwelche Debuglogs von der ReGa zu aktivieren.

Weitere Info: Das erste Rega mit der PID 913 konnte gekillt werden. Der zweite Rega Prozess mit dem SH Zombie Prozess konnte ich auch nicht mit kill beenden. Nach kill des ersten Prozesses läuft auch die webui nicht mehr.

Kleiner Tip am Rande:
Du kannst mittels eines "kill -9 PID" mit der PID des zweiten ReGa Prozesses diesen Prozess mit seinem Zombie Child killen, wodurch sofort der erste ReGa Prozess aufwacht und die angestauten Programme abarbeitet - Achtung! Dabei kann dann auch schon mal die Alarmanlage losgehen, wenn man sie mit Homematic realisiert hat

Ansonsten müsste ich noch mal auf das vorherige Betriebssystem wechseln (das will ich doch eigentlich gar nicht).

Bei mir ist das jetzt seit 2 Releases, aber vorher war die HUE Integration auch noch nicht wirklich vorhanden...

Gerade versuche ich HUE mal komplett rauszuwerfen und die Kopplung neu zu machen - scheitere allerdings gerade daran, dass ich eines der HUE Geräte nicht aus der RM löschen kann...

S

[homie_]

Hallo,
ich bin jetzt erst mal auf die letzte Raspimatic Version zurückgegangen. Mal sehen ob da der Fehler der Fehler auch auftritt. Melde mich.
Falls Du was neues rauskriegst bitte um Info!
Danke und
Schönen "Rest der Woche" ...