Seit einiger Zeit (ca. 2 bis 3 Wochen) beendet sich IP-Symcon etwa alle 4 Tage (aber nicht „exakt“ 4 * 24 h) von selbst. Die erzeugten Logdateien sind völlig unauffällig. Alle erzeugten CrashDump__XXXXX.dmp-Dateien sind jedoch leer.
Man kann den Dienst anschließend wieder manuell starten. Die konkrete Ursache des Absturzes ist daher unklar.
Es gibt eine gewisse (aber nicht eindeutige) zeitliche Korrelation mit der Verwendung des Github-Moduls von Esera-Automation (1-Wire über den Controller II dieses Herstellers). Das Problem trat bereits mit IPS 4.1 auf, bleibt jedoch nach Upgrade auf 4.2. bestehen.
IPS läuft auf Windows 10 32bit, PC: Zotac ZBOX. Welche weitergehende Diagnosemöglichkeit gibt es? Ist das Problem bereits bekannt?
Ich habe das jetzt längere Zeit mal beobachtet: Die Werte der Speicherinanspruchnahme liegen immer zwischen 23.5 und 36,1 MB. Es gibt auch keine Tendenz, weder nach oben noch nach unten.
Inwischen waren am Sonntag morgen wieder mal die „ca. 4 Tage“ 'rum, und der Dienst hat sich kurz nach 5:00 Uhr beendet.
Die Minidump-Dateien sind weiterhin leer.
Ich habe mir noch mal die Logdateien angesehen, die zu den Zeiten gehören, bei denen der Dienst beendet wurde.
Es passiert offenbar beim Protokollieren ganz unterschiedlicher Ereignisse
Es passiert mitten im Schreiben der Logdatei (= mitten in der Zeile bricht es ab, aber auch nie an der gleichen Stelle).
Was kann ich noch tun, um den Fehler zu diagnostizieren?
SymconMisc (benutzt wird Geofencing per Android)
IQL4Symcon
IPS-Module (git://github.com/ESERA-Automation/IPS-Module.git) [für 1-Wire-Controller von Esera-Automation]
Die ersten beiden sind schon längere Zeit im Einsatz und waren nie auffällig.
Beim dritten Modul könnte u.U. eine zeitliche Übereinstimmung mit dem Auftreten des Fehlers bestehen. Soll ich es probeweise mal 'rauswerfen?
Ich denke das wird nicht notwendig sein. Wir haben für ein ähnliches Problem eine Lösung in der 4.3 Beta, sodass dein Problem wahrscheinlich sich auch lösen wird. Es wäre cool, wenn du die mal ausprobieren könntest.
Seltsamerweise kann ich das Test-Update nicht installieren:
Nach Umstellung auf „Testing“ wird „Neueste Version: 4.3 #1505“ als Updaten angeboten. Das kann man dann herunterladen mit Meldung „Download erfolgreich“ (geht aber für meine Begriffe sehr schnell; vielleicht wird gar nichts heruntergeladen?).
Betätigt man dann „Update starten“ geschieht gar nichts…
Ich habe gestern abend (ohne irgendwelche Änderungen am System vorzunehmen) noch einmal versucht, auf 4.3 (Test) zu updaten - da ging es. => Ich werde verfolgen, ob der beschriebene Fehler wieder auftritt und berichten.
Hier kurzer Zwischenbericht zu Version 4.3 (Test):
Dienst läuft bisher ohne „Absturz“ (die magischen "4 Tage sind aber noch nicht vorbei…)
Variablen, für die eine Aufzeichnung vereinbart ist, werden im Webfront erwartungsgemäß als Verlaufsgrafik angezeigt, wenn man diese im Browser auf einem PC aufruft (sowohl direkt als auch über Symcon Connect); dagegen mittels „Symcon Connect“ auf dem Android-Handy (hier: Huawei P10 Plus) wird jedoch nichts angezeigt (leere Grafiken). Die zugehörige Meldung lautet „In diesem Zeitraum sind keine Datensätze vorhanden.“
Unter Version 4.2 ging das dagegen (mit den gleichen Variablen) problemlos.
Ob der Fehler prinzipiell ein Problem mit der Android-App darstellt oder nur die Kombination App/Symcon Connect betrifft, kann ich erst heute abend prüfen.
Das wird sicherlich an der App liegen - wir sind gerade dabei die Apps für IP-Symcon 4.3 zu überarbeiten, da es dort eine Menge Verbesserungen gab, welche zum Teil leider nicht mit der aktuellen App kompatibel sind.
Falls du iOS hast, haben wir eine aktualisierte Version bereits als Beta über TestFlight verfügbar.
Gesterrn waren wieder die „4 Tage“ vorbei, und der Dienst hat sich beendet…
Die *.dmp-Datei war wiederum leer, aber es gab diesmal Auffälligkeiten in der Logdatei wenige Minuten vor dem Crash:
Zuerst tritt „immer mal“ der folgende Eintrag auf, den es vorher in der Logdatei überhaupt nicht gibt:
00:49:00 | 00000 | MESSAGE | ScriptEngine | Zu viele gleichzeitige Skripte. Verwerfe Ausführung…
(aber immer noch unterbrochen durch „normale“ Einträge.)
In den nächsten Minuten folgt dann ununterbrochen bis zum Absturz nach 4 min:
00:50:07 | 18911 | ERROR | FlowHandler | Kann Daten nicht zur Instanz #18911 weiterleiten: Zu viele gleichzeitige Skripte. Verwerfe Ausführung…
Instanz #18911 ist der Splitter des Esera–Controllers, der mit dem Github-Modul von Esera-Automation in’s System gekommen ist.
Somit verdichten sich der Verdacht, dass es an diesem Modul liegt. Ich habe jetzt probeweise den TCP-Client deaktiviert, der die Messages aus dem Controller an den Splitter leitet, so dass dieser keine Skripts auslösen dürfte.
Das Verhalten wird weiter beobachtet.
00:50:07 | 18911 | ERROR | FlowHandler | Kann Daten nicht zur Instanz #18911 weiterleiten: Zu viele gleichzeitige Skripte. Verwerfe Ausführung…
habe ich heute nacht um 1uhr auch das erste mal gehabt, habe auch ein Modul in Verdacht
01:03:26 | 25052 | ERROR | FlowHandler | Kann Daten nicht zur Instanz #25052 weiterleiten: <br />
<b>Fatal error</b>: Out of memory (allocated 2359296) (tried to allocate 3072 bytes) in <b>C:\IP-Symcon\modules\IPSHomematicExtended\HMBase.php</b> on line <b>511</b><br />
01:03:26 | 40177 | ERROR | TimerPool | IPS2Enigma (DataUpdate): <br />
<b>Fatal error</b>: Out of memory (allocated 1310720) (tried to allocate 3072 bytes) in <b>C:\IP-Symcon\scripts__compatibility.inc.php</b> on line <b>4418</b><br />
Wie angekündigt habe ich den Übernahme der vom ESERA-One-Wire-Controller eingehenden Daten in das Esera-Github-Modul per TCP-Client abgeschaltet. Seitdem hat es weder Abstürze noch merkwürdige Meldungen gegeben. => Ich informiere Esera Automation mit Bitte um Fehlersuche im zur Verfügung gestellten IP-Symcon-Modul.
Magst du mir noch kurz sagen wie viele Geräte (=Instanzen) du von ESERA angeschlossen hast?
Welche Instanzen hast du genau davon? z.B. auch die „1-Wire Controller 2 - Ein- und Ausgänge“ Instanz?
Magst du mal unter Expertenansicht hinzufügen -> PHP Informationen schauen, wie sehr die PHP Threads ausgelastet sind?
Ggf. hilft es, wenn du bei den Spezialschaltern den PHP Thread Count auf z.B. 20 setzt.