Hi ralf,
kannst du den Crash mit gdb nachstellen? Die sind immer besser als die automatisch erstellten, welche wir „nach“ dem Absturz haben. Wie auch im deinem Fall, sind dort oft kaum sinnvolle Informationen 
paresy
Da jetzt das „Hauptproblem“ behoben ist, schaue ich mir gerade mal die anderen Themen an, die noch offen sind, und habe mir dabei diesen Fehler angeschaut. Leider kann ich das Verhalten nicht nachstellen. Kannst du das reproduzieren? Und was genau löschst du hierfür wann?
Ich habe noch einen Absturzbericht hochgeladen, gdb muss ich sehen, ob das wieder passiert.
Update:
Gerade wieder während der Aggregation abgestürzt, ich habe jetzt mal mit gdb gestartet und lasse gleich wieder aggregieren.
Update2:
Die Ausgabe vom gdb ist auf dem Weg an office@…
Sorry wenn ich das nochmal aufnehme aber würde ich auch gut finden. Klar kann man mit Skripten alles basteln. Aber da wäre mir eine zentrale Stelle und Lösung lieber.
Leider ist dieser Fehler noch da, die Aggregation nimmt für eine Weile massiv die CPU Kerne in Beschlag, dann nach ca. 80% meiner 1.05 GB bleibt die Aggregation bei einer Variablen (verschiedene) mit sehr vielen Datensätzen stehen. Die CPU Last geht zurück, die Graphen in den Visualisierungen zicken rum „TimeoutException“, einiges bekommt symcon nicht mehr mit, die Konsole aktualisiert nicht mehr, aber der tail auf der shell läuft noch.
Und irgendwann (bald) stürzt symcon wieder ab.
Update:
Too many scripts at once. Dropping execution...
inzwischen auch aus Modulen, es wird also nicht mehr lange dauern :(.
Hallo Paresy
Wenn ich das so lese:
So ähnliche?? Probleme hatte ich auch und bin deshalb wieder zurück auf ältere Version.
Da kam auch was mit zu viele Scripte…
Ich dachte das liegt an meinem Intel NUC…
Schönen Gruß:)
Egon
@ralf: Niels ist schon dabei das Problem zu analysieren. (Danke für den gdb Dump!)
Es scheint noch irgendeinen Deadlock zu geben, der alles blockiert und zu genau diesen Probleme führen kann.
paresy
Moin,
nach dem Neustart mit Version vom 26.10. hatte ich diese Anzeige.
IPS konnte nur noch via Task Manager beendet werden. Das angezeigte Skript muss bei mir laufen, wenn ich alle Daten vom Entwicklungssystem auf das Produktivsystem kopiere.
Nach einem kompletten WIN/IPS Neustart hat dann alles wieder funktioniert. Es erschien auch das Fenster mit der unbekannten CPU und die Reaggregation lief dann danach komplett durch.
Gruß
Hans
Danke für die Info, gdb läuft wieder, aber erstmal ohne Reaggregieren, Wenn ich helfen/debuggen kann, just ping me :D.
Update:
Was mich irritiert ist, dass ich ein paar Variablen mit grauem Ausrufezeichen habe, die werden nicht geloggt und ich würde wetten, dass das auch noch nie eingeschaltet war. Ich würde definitiv keine MAC Adresse loggen :o.
Ich habe einige davon jetzt gelöscht und lasse die Reaggregation noch einmal laufen.
Moin Niels,
ja, ich kann das reproduzieren. Wenn die Batch Übernahme der Sportdaten auf den Fehler mit dem Deadlock trifft, ich danach das komplette db-Verzeichnis lösche, dann ist dieser Fehler mehrfach - aber nicht immer - aufgetreten.
Ähnlich wie bei Ralf unterliegt das leider alles einer gewissen Stochastik, was die Sache ja so kompliziert für euch macht 
Gruß
Hans
@ralf: Dank deines Crash Dumps habe ich eine mögliche problematische Stelle gefunden. Ich habe mal einen Fix dafür gebaut. Installiere den bitte mal bei dir und teste, ob es damit läuft. Hier der Download, ich hoffe ich hatte das mit Raspi korrekt parat:
https://apt.symcon.de/pool/symcon/rpi/symcon_5.5-88-fixes-aggregation-deadlock_armhf.deb
PI ist korrekt, die Reaggregation ist durchgelaufen und hat ca. 11 Minuten gedauert, bei 1.05 GB und ca. 63.5 Millionen Datensätzen.
Damit scheinst du zumindest für das Problem bei mir den Fehler gefunden zu haben.
DANKE, ich bin mir wieder mal absolut sicher, das meine Entscheidung für Symcon vor mehr als 15 Jahren eine meiner Besten war 
.
Was mir bei Zusehen aufgefallen ist, es werden ja scheinbar mehrere Variablen parallel aggregiert, zumindest sind alle 4 Cores ausgelastet. Aber im Fenster wird immer nur eine Variable angezeigt. Das macht manchmal einen komischen Eindruck, da eine Variable mit sehr wenigen Datensätze mehrere Sekunden sichtbar ist und eine Variable mit extrem vielen Datensätze kann man kaum lesen, so schnell ist sie weg.
Update:
Du hast irgendetwas bei den Profilen kaputt gemacht, alle meine geloggten Variablen haben ein „Invalid profile“ im Objektbaum. In den Eigenschaften steht das Profil korrekt drin.
Ja, wir haben uns dazu entschieden, dass einfach alle Mitteilungen dort angezeigt werden und nicht etwa nach Kernen aufgeteilt wird. Die entscheidende Information ist hier „Das System arbeitet für dich“ und wenn es hängt, dann sieht man wodran es hängt. Details kann man bei Bedarf dem Log entnehmen. Die Informationen nach Kernen aufzuteilen würde zum einen recht viel Buchhaltung erfordern und zum anderen sieht es bei vielen Kernen irgendwann echt doof aus.
edit:
Bei den Profilen habe ich eigentlich nichts gemacht… Kannst du mir vielleicht mal deine settings.json schicken? Dann schaue ich mir das mal an. Und wie sieht es im WebFront aus? Funktionieren die Profile dort wie vorgesehen?
Konsole beendet und neu gestartet, nun passt es wieder :).
Hatte ich letztens auch schon von berichtet…
https://www.symcon.de/forum/threads/44791-gel%C3%B6st-Jede-Menge-Variable-mit-Invalid-profil-seit-V5-5-RC1?p=438465#post438465
Habt ihr vielleicht nur übersehen.
Gruß
lueralba
Mir ist noch aufgefallen, dass jetzt bei einige Diagrammen „Timestamps need to be in the correct order“ oder „The timestamp of a bool value is too early for the start time of the graph“ angezeigt wird.
In der Stundenansicht werden teilweise Diagramme angezeigt, das ist im Webfront und IPSView identisch.
Das sind alles Bool Variablen, die schon ewig aufgezeichnet werden. Eine erneute Reaggregation ist durchgelaufen, die Meldung ist bei einigen Variablen weg, bei anderen nicht.
@ralf: Kannst du mir die entsprechenden Variablendaten mal schicken, Rohdaten und aggregierte Daten? Dann schaue ich mir das gerne mal an.
@lueralba: Ah, stimmt, danke für den Hinweis! Ich konnte das bei mir aber auch nicht mit einem Neustart nachstellen. Kannst du das bei dir noch nachstellen, wenn du die Konsole beim Neustart offen hast? Vielleicht dauert ja bei dir irgend etwas länger beim Start, was bei mir nicht zutrifft…
Hallo Ralf,
ich habe mir die Daten gerade einmal angeschaut. Danke dafür!
Bei Boolean-Variablen sollte die Reaggregation eigentlich irrelevant sein, da hier ja immer direkt auf den Rohwerten gearbeitet wird. Und dort liegt bei der Variablen, die du mir geschickt hast, auch das Problem. Ich habe einen Fall entdeckt, in dem vier Zeilen sich direkt wiederholen und dadurch den Fehler verursachen. Machst du irgendwas mit deinen Daten? Fügst du per Skript Datensätze hinzu oder dergleichen? Oder loggst du die einfach „nur“?
Ich habe die Dateien noch nie angefasst und mache auch nichts damit. Das Beispiel ist ein Bewegungsmelder, der schon sehr lange in meinem Büro hängt und aufgezeichnet wird.
Weitere 6 BWM haben die gleiche Fehlermeldung und dann eventuell das gleiche Problem.
Die Diagramme wurden bis gestern, vor deiner Interimversion, immer angezeigt.
Die Zwischenversion sollte eigentlich mit dem Verhalten nichts zu tun haben. Die Änderungen betrafen auch nur die Reaggregation. Hast du zu den problematischen Zeiten vielleicht reaggregiert?