ExecEngine scheint mehrfach zu laufen

[Familienvater]

Moin,

dann gebe ich auch noch mal kurz meinen Senf dazu ab:
Probleme in VisuWin, wenn die Uhr nicht läuft, deuten auf Probleme mit der IP-Kommunikation hin, weil die "Push"-Nachrichten von der CCU nicht ankommen, der initialzustand wird gepollt. Wenn die Uhr irgendwann wie verrückt anfängt zu rennen, würde mir das extrem zu denken geben, weil dann irgendwas die CCU massiv auslastet.
Das können Zombie-Instanzen sein, eine oder mehrere offene WebUI-Sessions.

Da aber wahrscheinlich die wenigsten ein dauerhaftes Monitoring ihrer CCU betreiben, wird das keinem auffallen, wenn das Schächtelchen am Anschlag arbeitet, weil ein Lüfter, der dann hochdreht, hat die Kiste zum Glück ja nicht.

Und ich würde leider bei dem System nichts pauschalieren, nur weil es bei Bümpi keine Probleme gibt, heißt das nicht, das es bei Rhobin auch keine Probleme geben muss.
Das fängt bei der Komplexität der Programme an, Anzahl der Variablen, Module, ja sogar statischer Text in den Makros, der zum eMail-Versand etc. genutzt wird, belegt so etwas wie einen Variablen-Index.

Die Art der Progammierung, ich habe das Gefühl, das viele hier im Forum Makros mit (kurzen) Ausführungsintervallen nutzen, obwohl das gar nicht notwendig ist, weil das meistens mit einem Trigger auf Empfang oder Änderung erledigt werden könnte.

Und ich habe persönlich das Gefühl, das die CCU1 in Verbindung mit den FHZ2000 sehr netzwerk-Sensitiv ist, je mehr Traffic im Netz, desto mehr Probleme mit der Verbindung zwischen CCU1 und FHZ2000 treten auf, wobei der Traffic nicht unbedingt heftiges GByteweise Dateien verscheiben sein muss, mehr der Low-Level-TCP/IP Traffic, ARP-Requests usw.
In meinem SoHo-Netzwerk, ausschließlich managebare GByte-Switche (keine Hubs), wo die Verbindung zwischen CCU und meinen 2 FHZ über 2-3 Switche läuft, gibt es mit steigender Anzahl laufender PCs im Netzwerk mehr Verbindungsneuaufbauten zwischen FHZ2000 und CCU1, soweit ich das mit Wireshark debuggen konnte hat immer die FHZ2000 die Verbindung neu aufgebaut, weil die CCU banal ausgedrückt, nicht schnell genug geantwortet hat. Dabei geht jedesmal ein bisschen Hauptspeicher der CCU verloren, bis der FHZ2000IF neu gestartet wird. Ich kann/will aber nicht ausschließen, das ich mir diese Probleme teilweise selbst mache, weil ich z.B. keinen USB-Stick, sondern eine NFS-Freigabe als Datenträger auf der CCU nutze, und da auch regelmäßig Daten drüber schreibe/lese. Ausserdem läuft mein Health-Monitoring der CCU, was auch alle 5min kurze Zeit die ein oder andere Ausgabe von Kommadozeilentools auswertet und verarbeitet.

Die Exec-Engine bzw. der Controll-Prozess hat meiner Meinung nach einen Watchdog, der die Ausführung neu startet, wenn eine gewisse Zeit "keine Antwort" von der ExecEngine kommt. Kann man ausprobieren, in dem man ein Makro schreibt, was sich selbst immer wieder neu aufruft (kein gehezu-Sprung nach oben, da bekommen andere Module auch mal an die Reihe), da ist nach ca. 15.000 "Rekursionen" Feierabend, entweder, weil der Stack geplatzt ist, oder weil keiner mehr Antwortet, auf jeden Fall startet dann die Ausführung neu.

Wenn meine selbstgeschrieben Tools z.B. erkennen, das die Ausführung meines HPCL-Projekts auf der CCU neu gestartet wurde, lassen die der CCU erstmal 120 Sekunden Zeit, damit HPCL alles auf die Reihe bringen kann, bevor die überhaupt erst anfangen, sich z.B. einmalig die Variablenliste per XMLRPC zu requesten. Alleine dieser Request dauert inzwischen bei meinem Projekt ca. 30-40 Sekunden, bis die Antwort mit ~3.000 Variablen/Objektennamen da ist, danach können meine Tools dann aber die paar Variablen, die sie benötigen, gezielt per Lfd-IndexNr. abfragen/setzen, das geht dann ratz fatz.
Ich finde es "gemein", wenn VisuWin schon läuft, und nur darauf wartet, das endlich eine ExecEninge antwortet, um die dann gleich zu traktieren. Wenn die Ausführung gestartet wird, hat die ExecEngine erstmal jedemenge zu tun, je mehr HM-Geräte angelernt sind, desto länger dauert es, bis z.B. alle Zustände der Geräte erstmal abgefragt wurden, bei 220V-Aktoren z.B. auch per Funk-Anfrage.

Egal, gute Nacht, der Familienvater

[painless]

Hallo Familienvater,

danke für Deine Ausführungen. Bin spät dran mit der Antwort, ich hatte wenig Zeit. Es gab seit dem 27.05. drei weitere Abstürze.

Bzgl. Deiner Fragen hier meine Antworten um mein Problem einzugrenzen:

Ich setzte die CCU1 mit 25 verschiedenen Modulen. Wieviele Aktoren das insgesamt sind, habe ich nie gezählt. Gibt es dazu eine Funktion / Programm welches die Anzahl ermittelt ? Auf jeden Fall wired mit 2*12 IO, aber auch schon seit Jahren.

Meine Homematic habe ich bereits abgeschaltet.

GeheZu nutze ich nicht.
Get/SetCCUSysvar nutze ich, aber was ist viel ? Auf jeden Fall nicht periodisch.
Periodisch läuft nur ein Wachtdog alle 30 Sekunden um ein paar Schalterzustände abzufragen.
StarteProgramm wenig und es hat auch vorher keine Probleme verursacht.
FZH2000 ist nicht im Einsatz.
getside ebenfalls nicht.

Summa summarum: Wenn ich Dein Projektumfang sehe, bin ich ein Zwerg.

Heute hatte ich wieder einen Absturz, checkrega.cgi meldete trotzdem ein OK. GUI war erreichbar, ebenfalls Telnet.
PS -grep zeigte 2 ExecEngine Zombies und ein tclsh Zombie (?).

Direktverknüpfungen liefen noch. Ich lasse noch per HTTP durch einen Bewegungssensor in einer Kamera eine CCU-Variable hochzählen:
URL: /blabla.exe&Antwort=dom.GetObject('Akt_Bewegung_hochzaehlen').State(1) [../Platform/Internet/http/iseSession.cpp (185)]
Dies funktionierte auch noch.

Nach meinem jetzigen Kenntnisstand funktioniert nur mein HPCL Projekt nicht mehr und nur reboot hilft.

df bringt nach reboot

Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock2 32768 26708 6060 82% /
/dev/mtdblock3 32768 6552 26216 20% /usr/local
tempfs 32768 660 32108 2% /var

und
/ # cat /proc/meminfo nach reboot zeigt

MemTotal: 62372 kB
MemFree: 11260 kB
Buffers: 0 kB
Cached: 20368 kB
SwapCached: 0 kB
Active: 28304 kB
Inactive: 14304 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 22260 kB
Mapped: 6300 kB
Slab: 5372 kB
SReclaimable: 1652 kB
SUnreclaim: 3720 kB
PageTables: 808 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 31184 kB
Committed_AS: 36768 kB
VmallocTotal: 956416 kB
VmallocUsed: 9692 kB
VmallocChunk: 940028 kB
/ #

Ich kann damit wenig anfangen. Worauf ist dabei zu achten ?

Hier ein Auszug aus dem SysLog, lt. CCU-Historian war ab 16:45 auch die Kommunikation gestört:

Jun 3 16:45:06 homematic user.err hs485d: HSSParameter::GetValue() id=STATE failed getting physical value.
Jun 3 16:45:07 homematic local0.info ReGaHss: Info: start web processing, worker thread #0 {"HTTP-Listener"} [../Platform/Internet/http/httpListener.cpp (205)]
Jun 3 16:45:07 homematic local0.info ReGaHss: Info: recvd 612 bytes by web server #0 [../Platform/Internet/http/httpServer.cpp (763)]
Jun 3 16:45:07 homematic local0.info ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe [../Platform/Internet/http/iseSession.cpp (185)]
Jun 3 16:45:07 homematic local0.info ReGaHss: Info: http id #0 sends parsed file [../Platform/Internet/http/httpServer.cpp (2026)]
Jun 3 16:45:08 homematic user.err hs485d: response timeout
Jun 3 16:45:08 homematic user.err hs485d: HS485PhysicalDataInterfaceCommand::GetData SendMessage failed for LEVEL_GET

Die letzte Programmänderung vor den Problemen war eine Feiertagsberechnung für die Heizungssteuerung und dies habe nach dem Absturz durch einen alten Sicherungsstand rückgängig gemacht und warte jetzt mal ab.

Eine Frage die nichts mit den o.g. Problemen zu tun hat, aber in der jetzigen Situation nervt:
Ich muss schon immer nach reboot der CCU1 mein Projekt neu einladen, da alle Zeittabellen (Anwesenheitssimu etc) gelöscht sind.
Kann man die Zeittabellen fixieren, so dass sie auch einen Reboot überleben ?

Danke für Deine Unterstützung.

VG

painless

[Familienvater]

Hi,

die Werte von df und meminfo wären zum Zeitpunkt des Absturzes interessanter gewesen.

Dein /usr/local mit 20% benutztem Speicher ist absolut OK, das scheidet schon mal aus.
/var sollte nach dem Reboot immer sehr leer sein, das ist so etwas wie eine Ramdisk, wenn da mehr als 10% in Use sind, würde mir das zu denken geben, ich habe aktuell 4%, nach fast 30 Tagen uptime.

meminfo sieht nach dem Reboot auch erstmal gut aus, aber auch da wäre der Zustand vor dem Reboot viel interessanter... In meinen Augen Kritisch wird es, wenn MemFree+Cached zusammen kleiner als 5-8 MB werden, dann ist fast kein freier Speicherplatz mehr vorhanden. Wenn MemFree gegen 0 geht, aber Cached noch 15 MB hat, ist alles OK, der gibt das im Bedarfsfall ab.

Mit wired habe ich leider gar keine Erfahrung, wenn Du einen Busabschlusswiderstand mit LEDs hast, ist da mehr geflackere als sonst? Vom Verständnis und der Erfahrung vom rfd-Log her würde ich sagen, das da Kommunikationsprobleme auf der wired-Seite sind, aber das ist "geraten", und zwar beim Abfragen eines Aktors/Sensors, LEVEL haben glaube ich sehr viele Aktoren, wie z.B. Licht/Dimmer/Rolladen.

Anwesenheitssimu nutze ich nicht, aber meine Zeittabellen habe ich in HPCL bei den Objekten angelegt, und übertrage diese mit jeder Version neu auf die CCU. Wenn man die Zeittabellen über VisuWin ändert, werden diese höchstens (bin mir da aber auch unsicher) gesichert, wenn die Ausführung sauber über Kontrolle ExecEngine beendet wird. Im Falle von Abstürzen oder Neustarts über die WebUI erfolgt kein sauberes Beenden der Ausführung, das ist eher mit Stecker-Raus beim PC vergleichbar.

Zombies: (ich habe bei mir die große busybox drauf, da ist auch ein pstree enthalten)

Code: Alles auswählen

pstree -p gibt bei mir folgendes aus:
....
        |-ctlstart(1275)---ctlexen(1280)-+-ExecEngine(1300)
        |                                |-ExecEngine(1866)---ExecEngine(2046)-+-ExecEngine(2047)
        |                                |                                     |-ExecEngine(2052)
        |                                |                                     `-ExecEngine(2100)
        |                                `-ctlexen(1297)---ctlexen(1298)
.....

Laut ps ist die ExecEngine mit der ProcessID 1300 ein Zombie, warum? Keine Ahnung Aber soweit geht bei mir alles, und auch die ExecEngine hat bei mir aktuell 25 Tage Uptime, da mache ich mir gerade wenig Sorgen.

Von den restlichen Beschreibung klingt das so, als ob es keine offensichtlichen Probleme geben sollte. Hast Du evtl. Makros von den wired-IO-Modulen auf Ausführen bei Empfang? Keine Ahnung, wie oft so ein Eingang was meldet, ob das nur bei einem Toggle ist, haben die 12* IO auch die Analogeingänge? Evtl. "feuern" die ja dauernd?

Ansonsten hilft es Dir wenig, aber ich schiede so etwas gerne auf digitalen Schluckauf , ich hatte auch schon Versionen von meinem Projekt, die öfters mal abgestürzt sind, dann habe ich gefummelt, und danach war gut, ohne das ich jetzt etwas gravierend geändert hätte. DAMALS hat z.B. eine Reduktion der startprogramm geholfen, aber das Thema würde ich inzwischen als ziemlich stabil ansehen, da hat Contronics noch einige Fehler rausgemacht, aber ich weiß natürlich nicht, welche "Schweinereien" Du machst...

Ich habe mir z.B. beim Neustart immer eine Mail gesendet, dann wusste ich, das da mal wieder was faul war, und ich habe teilweise mit Level 3 die history.hst geschrieben, um darin evtl. noch die letzten Dinge vor dem Absturz rausfummeln zu können.

Mehr fällt mir jetzt auch nicht mehr ein, Nächtle...

[rhobin]

Hallo painless,

Ich habe auch monatelang nach Ursachen gesucht, LOG-Files gepostet, meminfo und pstrees diskutiert usw. usw. - niemand konnte mir helfen.

Seit ich ganz konsequent alle periodischen SET-/GETSYSVAR-Befehle rausgeschmissen habe, hat sich zumindest die Zombie-Problematik erledigt.

Bei mir war es vor allem ein Watchdog-Makro, dass regelmässig ein Systemvariable (Zeit) von der CCU abgeholt hat.

Etwa zur gleichen Zeit bin ich angefangen, das händische Übertragungsverfahren konsequent einzusetzen und seitdem ist an der Zombie-Front Ruhe.

Auf uptimes von > 20 Tagen komme ich immer noch nicht, weil nach 5-6-Tagen Uptime der ExecEngine und nach 14 - 16 Tagen Uptime der CCU1 einfach manche Programme spinnen - ich hab's aufgegeben, nach den Ursachen zu forschen. Meine Hoffnungen setze ich auf den Einsatz der neuen LXCCU auf einem Raspi mit einem Funk- und einem Wired-Adapter. Aber das habe ich noch nicht produktiv.

Gruß
Rhobin