heute nacht ist er wieder abgestürzt
den Fehler mit der fehlgeschlagenen Installation hab ich nun gefunden. Im docker war der temp Ordner bereits eingebunden. Hab diese Verbindungn nun gelöscht und es lässt sich installieren. Jetzt nur noch auf den nächsten Absturz warten.
Habe aktuell die Datenbank extrem reduziert um nach einem Neustart einen schnelleren Start zu bekommen.
Allerdings stürzt aktuell immer noch ab, beinahe täglich. Wo kann ich das Logfile auswerten? Danke euch
Hi,
welches Logfile? Für IPS hast Du ja ein Volume für Logs angegeben und da musst Du dann z.B. per FTP rauf. Log mit der höchsten Nummer ist das Letzte. Bei Docker gibt es in der App eine Option Protokoll wo Du nachsehen kannst.
Bist Du sicher das es ein Absturz ist? Absturz hatte ich mit meiner Synology noch nie aber den Zustand das IPS praktisch gar nicht mehr reagierte und das habe ich mit Scripten geschafft die nie beendet wurden und irgendwann war die maximale Anzahl der Threads erreicht.
Ralf
Hi Ralf
wie paresy am anfang geschrieben hat habe ich folgendes ausgeführt https://community.symcon.de/t/debugging-fuer-experten-docker/121549
jetzt sollte da etwas geloggt werden worauf man den Absturz zurückschließen kann.
Ich weis was du meinst, dass hier scripte bis zur unendlichkeit laufen. Das hatte ich auch schon mal. aktuell stürzt der Docker unregelmäßig ab. Tagsüber Nachts mal nach 1 Tag mal nach 20 Tagen. Ich bekomme ein Mail über mein Synology, dass der Container unerwartet neu gestartet wurde.
andere Container stürzen nie ab. auch mein Bastel Symcon Container stürzt nie ab. Auch wenn dieser Container ausgeschaltet ist stürzt trotzdem das Hauptsystem ab.
Weil nach dem Absturz alle Variable neu aggregiert werden und das dann teilweise 20 min gedauert hat, habe ich mein Archiv extrem reduziert, sodass ich auf 2min komme. trotzdem stürzt das ab.
Logfiles schau ich mal durch. Teilweise sind die >500 MB pro Tag
Das waren die letzten Einträge vor dem Absturz
01.05.2023 22:22:03 | 24465 | DEBUG | VariableManager | [Hardware\Shelly\Messen Solar\E8DB84D36EC5 - Solarstrom\Energie] = 73.0257166667
01.05.2023 22:22:03 | 40176 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 37426 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: Timer: RoborockQueue
01.05.2023 22:22:03 | 37426 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: Timer: RoborockQueue ~ Dauer: 1 ms
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 36607 | DEBUG | VariableManager | [! Baustelle\Shelly\7A1953 - Garten Baustelle\Leistung] = 0.0000000000
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 44385 | DEBUG | VariableManager | [! Baustelle\Shelly\7A1953 - Garten Baustelle\Energie] = 0.0270333333
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 18394 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausführung von PHP-Modul ~ Aktion: ReceiveData
01.05.2023 22:22:03 | 29577 | DEBUG | VariableManager | [! Baustelle\Shelly\7A1953 - Garten Baustelle\Status] = false
01.05.2023 22:22:03 | 28421 | DEBUG | ScriptEngine | Ausgeführt von PHP-Modul ~ Aktion: ReceiveData ~ Dauer: 1 ms
Hi,
was bei Paresy fehlte war der Hinweis auf das Protokoll von Docker auf der Synology. Das half mir schon wenn ich z.B. bei Z2M falsche Schnittstelle angegeben hatte oder die USB-Treiber nicht installiert waren.
Ralf
wo kann ich das finden?
Hi,
ich bin bei DSM 7.2RC da ist alles anders. Ich meine es wäre bei der Dockerübersicht, Docker markieren und dann Details. Oben sollte dann auch ein Reiter mit Protokoll sein.
Ralf
Hi Ralf ich hab auch DSM7
rwenn der Docker Container abstürzt sieht man da auch Nix mehr im Log weil der ja dann aus ist. oder versteh ich da was ganz falsch?
Hi,
ich habe 7.2RC die es seit einigen Tagen gibt. Ich bin halt verspielt.
Was das Protokoll angeht kommt es auf den Absturz an wie beim PC auch. Wenn ein Programm sich z.B. mit einem Division / 0 verabschiedet sieht man es. Wenn es aber auf Kernelebene einen harten Reboot gibt sieht man es nicht mehr.
Es kann auf keinen Fall schaden auch im Docker-Log nachzusehen.
Ich sehe bei mir für IPS z.B. „/dev/sata1: open: Datei oder Verzeichnis nicht gefunden“ weil ich im Docker bin und es dieses Gerät da nicht gibt.
Ralf
Hi @tommy86,
hattest du es denn jetzt im Container hin bekommen, dass dort gdb läuft? Ansonsten würde ich dir gerne anbieten, dass wir uns dies zusammen in einer Remote Sitzung sonst mal nächsten ansehen und schnell einrichten um dem Problem auf die schliche zu kommen. Falls du es noch nicht nutzt, kannst du aber auch gerne mal auf die 6.4 gehen - falls ggf. das Problem dort schon gelöst sein sollte.
paresy
Hallo
Vielen Dank für das Angebot. In dem alten Docker hatte ich das gdb am laufen. Allerdings konnte ich den Fehler nicht finden, bzw das passende Logfile zu finden. Aktuell hab ich 6.3 09.02.2023 am laufen
Gestern habe ich das ganze nochmal neu aufgesetzt. Also den Docker neu angelegt. Das aktuelle Image neu Heruntergeladen und alles neu aufgesetzt. Ich werde jetzt mal die Tage schauen ob es nochmal abstürzt. Manchmal dauert es auch bis zu 20 Tage bis es passiert.
Division durch 0 hab ich auch überall abgefangen soweit ich mir das finden kann.
Beste Grüße schon mal jetzt
Thomas
extrem komisch. jetzt ist der Container 10 Tage ohne Probleme gelaufen und nun innerhalb einer stunde gleich 2 mal abgestürzt.
Änderungen an der Programmierung hab ich in dieser Zeit nicht vorgenommen
Wieder ein paar Abstürze gehabt. Heute hab ich es sogar mit erlebt.
Interne Sachen über KNX ausgelöste Sachen gingen noch sofort.
Will ich was zur gleichen Zeit über ipsview anpassen reagiert es nicht mehr.
evtl hängt es auch mit diesem thema zusammen
bei mir meldet sich das KNX Gateway auch immer wieder vom netz ab. Habe ich gerade herausgefunden
Hallo Tommy,
ich habe inzwischen drei IP Gateways an einer Symbox. Läuft absolut stabil. Auch am vorherigen Raspi gab es keinerlei Probleme mehr.
VG, Joerg
Ich hab das Gateway von MDT (LAN)
jetzt ist heute das ganze System bestimmt 5x seit 7 Uhr abgeschmiert
hab jetzt das KNX Gateway im Symcon deaktiviert. Seit dem ist noch kein Absturz.
scheinbar wirklich was mit dem Gateway nicht korrekt. lief eigentlich 2 Jahre super bist jetzt die letzten 3-5 Monate immer mal wieder ein Abschuss kommt
Ich habe ein MDT SCN – IP 000.03, ein Jung IPS 300 REG und ein Weinzierl 7831 im Einsatz.
Bei mir war eine damals eine alte Variable schuld.
Ich habe auch in ca. 20 Kundeninstallationen keinerlei Probleme. Verwende hier inzwischen nur noch deas ISE Smart Connect KNX Remote.
Viele Grüße
JOerg
Mit freundlichen Grüßen
Joerg Wiederhold
Wiederhold
Planung-Projektierung-Programmierung
Niederhofenstraße 36
71229 Leonberg
Tel: +49 7152 76 48 653
Fax: +49 7152 76 48 654
Mobil: +49 173 47 80 533
