leider habe ich eine ähnliche Situation. IP-Syscon lief plötzlich nicht mehr und ich bekomme folgende Fehlermeldung:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x644ff430 (LWP 7298)]
0x00329f48 in ALLUniversal::UpdateValues() ()
(gdb) bt #0 0x00329f48 in ALLUniversal::UpdateValues() () #1 0x00b08354 in std::_Impl<std::_Bind_simple<IPSTimerPool::processTimers()::{lambda()#1} ()> >::_M_run() () #2 0x768f8348 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Habe auch schon IP-Symcon deinstalliert und wieder installiert, mit der Beta-Version versucht, aber der Dienst startet einfach nicht mehr…
@Klaus: Das Problem sollte bereits in der aktuellen Beta-Version gelöst sein. @home: Hast du evtl. schon neue Infos welche Variable es bei dir betrifft?
Ich habe auch seit meinem letzen Update (vor ca 1,5 Wochen) regelmäßig Abstürze von IP-Symcon (läuft ca einen Tag). Ich habe auch einen Raspi und noch IPS-Studion laufen. Ich hatte leider noch keine Zeit für Fehleranalyse. Beim ersten überfliegen der Linux-Logs und Symcon-Logs habe ich nichts auffälliges gefunden. Bei Gelegenheit versuche ich nochmal mehr rauszufinden.
wir haben das Problem nachstellen können. Nachher kommt ein entsprechender Fix auf den Beta-Kanal.
Es wurden wohl Nachrichten verschickt, die zu kurz waren. Nach Protokoll muss eine FHZ-Nachricht mindestens 4 Byte lang sein. Dies wurde allerdings von unserer Seite her bisher nicht geprüft, so dass ungültige, kürzere Nachrichten Fehler verursachen konnten. Dies haben wir jetzt behoben und zu kurze Nachrichten werden korrekt abgelehnt.
Ich hatte nun seit gestern keinen Absturz mehr und dachte das Problem läge woanders. Ich hatte gestern noch in einem Workflow in IPS-Studio einen Fehler (Situation muss ich separat klären) gefunden und geändert. Ich dachte das Problem kommt aus diesem Bereich. Der hat aber mit FHZ nichts zu tun (dort wird ein z-Wave Schalter betätigt). Auch sollte so ein Fehler ja auch nicht zu einem Absturz führen…
Ich muss also die nächste Beta einspielen um den Fehler zu korrigieren?
Ich leide leider auch unter Crashs … Neustart war gestern Abend nach gleichem Fehler - heute Mittag um 16 Uhr war leider wieder der obige Fehler zu sehen und ich muss den Server neustart.
Ich habe in der letzten Zeit nur Charts ins Webfront eingebunden und ein größeres Curl Script für den Wechselrichter laufen
Steht doch mehr oder weniger da, zu viele Skripte. Hast Du denn mal Expertenansicht PHP informationen geschaut wie viele Skripte laufen und vor allem was das für Skripte sind? Wenn der Rechner Luft hat, dann einfach unter Spezialschalter anzeigen die Anzahl des Threads hochstellen. Auf was ist das denn zur Zeit eingestellt bei Dir und auf welcher Maschine läuft IPS?
Hmmm … Ich habe schon Mal in der Expertenansicht geschaut und im Normalfall sind selten alle 10 threats aktiv. Ich habe irgendwie das Gefühl das sich eine quer legt und die threats blockiert und nicht mehr frei gibt? Somit wären mehr threats keine Lösung - auch müsste das housekeeping Langläufer killen und die habe ich nicht … Soweit ich weiß.
Ich habe das curl script in Verdacht aber es ist eben nur so einer …
Um den Verdacht zu prüfen könntest du die Aufrufe des Skriptes ja mal rausnehmen. Je nachdem, ob das System dann weiterhin crasht oder nicht, wissen wir, ob der Verdacht begründet war.
Und nochmal zum FHZ-Gerät: Der Fix ist mittlerweile auf dem Beta-Kanal verfügbar. Um den zu nutzen müsstest du den Update-Kanal auf „Beta“ ändern, falls er aktuell auf „Stable“ steht.
Der Fix löst allerdings nur das Symptom und verhindert bei fehlerhaften Nachrichten einen Absturz. Dennoch scheint dein System irgendwo fehlerhafte Nachrichten zu verschicken. Daher würde ich dir empfehlen, das noch einmal zu prüfen. Verschickt ein Skript oder ein Modul vielleicht problematische Nachrichten?
Ich habe die problematische Funktion ParseBuffer noch einmal überprüft und finde keine Stelle, an der dieser Fehler fliegen könnte. Ist dein System auf dem aktuellen Stand? Kannst du mir mal deine Kernel-Version schicken?
hatte gestern 2 Abstürze… inner halb von ca. 2 Std.
Nach dem ersten hab ich die Hälfte der hinzugenommenen Graphen wieder deaktiviert… sprich ich hatte dann 81.25% der Graphen aktiv… und dann kam kurze Zeit später der 2. Absturz.
… und wieder halbiert… bin jetzt auf ca. 78% aktivierter Graphen.
ist muehsam… ich hoffte wir koennen irgend ein besseres Mittel einführen um das Problem zu fangen… sprich wenn ihr glaubt, daS es an den Graphen und deren updates im webfront liegen könnte, dann muessten sich doch entsprechende Teile des codes instrumentieren lassen…, oder ?
Es tut mir leid, dass die Suche sich so aufwendig gestaltet. Leider haben wir bisher keine Idee woran es wirklich liegt. Ist ein einzelner Graph irgendwie problematisch und es gibt Probleme sobald dieser in der Gesamtmenge ist? Oder taucht das Problem auf sobald eine gewisse Anzahl an Graphen im WebFront eingebunden ist?
:_Impl<std::_Bind_simple<IPSTimerPool::processTimers()::{lambda()#1} ()> >::_M_run() ()
Klaus