Mein symcon läuft seit Jahren im Docker als Image. Aktuell das neuste stable. Es passiert immer wieder dass der Container abstürzt. Also nur das symcon.
Gibt es irgendwelche Möglichkeiten die Ursache heraus zu finden? Das nas hat 8gb RAM. Wie viel sollte symcon zugewiesen werden
Gibt es ein log in dem man den Grund des Absturzes erkennen kann?
Hi,
mein Symcon läuft auch unter Docker auf einem NAS. Ich habe IPS hohe Priorität und 4GB erlaubt. Da IPS ja auch auf RaspBerries läuft sollten 2GB wohl auch reichen.
Bei meine NAS (Synology) führt Docker für jedes Image auch ein Protokoll. Da schon mal reingeschaut?
ich hab das Synology NAS neu installiert. Es gab so einige Probleme. z.b. nach einem Neustart hat allein der Docker Start 14 min gebraucht. jetzt läuft das wieder.
NAS hat 8GB RAM und im Docker hab ich keine Begrenzung drin. Mal sehen wie es sich entwickelt. aktuell läuft es schon über 24h durch
Hmm leider stürtz das System immer noch regelmäßig ab. habe ich einen zweiten Docker mit Symcon parallel laufen stürzt dieser nie ab. liegt also scheinbar an irgendwelchen scripten oder modulen, die das System dann beenden.
will ich aber die Diagnose wie in dem Link vorgeschlagen installieren passiert folgendes:
Den Tip mit dem Debugging wollte ich probieren. Es lässt sich allerdings nicht wie beschreiben im docker installieren (siehe Sceenshot). Muss ich da noch was beachten?
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.
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
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.
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.
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.
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.