[Gelöst] (v1.5.1) TWS950 Absturz in der Nacht

[StefanW]

Hallo Sven,

was aus der Antwort von Matthias nicht so gut hervorgeht:

Wir haben Deinen Fall gestern ausgiebig in der Entwicklerkonferenz besprochen und mehrere Entwickler haben sich das auch angesehen.

Die einhellige Meinung ist, dass es NICHTS mit Timern oder vielen Paketen auf einmal zu tun hat. So einen Rush müssen die Stacks selbstverständlich abkönnen, die KNX Telegramme werden bis zum Timeout gepuffert. Es ist auch ein Zufall mit 1:00 Uhr morgens, weil die Probleme sind im Log bereits um 0:55 Uhr ersichtlich, ausgelöst durch den ständigen Wiederstarts eines sich selbst stoppenden Containers.

Wir prüfen unsererseits ob wir am Kernel was verbessern können, damit der Server auch soetwas jahrelang aushält (und wie man eine Warnung generiert dass solcherlei passiert).

lg

Stefan

[Robosoc]

Durch welche Einstellung im Portainer kann ich einen solchen andauernden Neustart denn erzeugt haben? Ist Euch das schon klar oder bekannt? Ich stehe d voll auf dem Schlauch, aber ich würde eigentlich gerne die aktuellste CV-Version als Testversion laufen haben

[StefanW]

Hallo Sven,

ich bin kein Portainer Spezialist, aber ich meine aus der Besprechung herausgehört zu haben, dass es eine Einstellung gibt, mit welcher der Portainer einen betreffenden Container neu startet, sofern dieser sich beendet. Womöglich ist das default.

Ich glaube der Punkt an dem man eher ansetzen muss ist, warum beendet sich der Container fast gleich sofort wieder. Das Neustarten wäre ja kein Thema, wenn es nicht sekündlich deshalb passieren würde, weil sich der Container nach dem Neustart gleich wieder verabschiedet.

lg

Stefan

[Robert_Mini]

Wie hast du den Container erstellt?

Die Anleitung ist hier:
https://www.cometvisu.org/CometVisu/en/ ... rwolf.html

Als "restart policy" ist dort "unless stopped" beschrieben, was auch sinnvoll ist, wenn der Container getestet funktioniert:

'Unless-stopped' restarts the container only when any user executes a command to stop the container, not when it fails because of an error. 'Always' restarts the container whether the it's caused by an error, or is executed by a user, or if Docker is restarted.

Mich wundert, dass die Visu überhaupt funktioniert, wenn der Container jede Minute startet??? Da kommt der eibd mit den knxread ja niemals hinterher und dein Bus müsste mit Telegrammen voll sein...

Was steht den im Log Filel des Containers?

Robert

[Matze76]

Hat denn dieser Container (also diese Test-Visu) tatsächlich jemals funktioniert? Das klingt ja eher so, als wenn es irgendwo während der Startbefehle schon zu einem Abbruch kommt, noch vor den knxreads. Aber ja, die Container-Logs sollten etwas sagen.

[Robosoc]

Danke Euch schon einmal für die Antworten und Vorschläge.

Im Log gibt es nur eine Zeile, diese aber 100te Male

Ich denke ich muss da einen Fehler in der Volume-Beschreibung oder so haben.

Wie hast du den Container erstellt?

Die Anleitung ist hier:
https://www.cometvisu.org/CometVisu/en/ ... rwolf.html

Exakt danach bin ich vorgegangen, allerdings nach der deutschen Version: hier. Trotzdem muss ich sicherlich irgendwo einen Fehler gemacht haben.

Ich konnte die Visu allerdings nutzen....

...jetzt denke ich kurz mal nach und habe es gestestet...
Ich dachte ich konnte die Testumgebung nutzen, aber jetzt wo ich den Container gestoppt habe, kann ich den Link https://timberwolf335/proxy/visutest/ noch immer nutzen. D.h. ich scheine in den Proxy-Einstellungen zwar erfolgreich eine neue Zeile angelegt zu haben, diese scheint aber auf den Container der App-CV zu verlinken....Autsch!

Restart-Einstellung:

[Robosoc]

Habe den Container (nicht das Volume) gerade noch einmal komplett neu nach Anleitung angelegt (cometvisu/cometvisu:testing-arm) und habe exakt das gleiche Fehlerbild. Der Container startet ständig neu. Habe versucht wirklich jeden Schritt der Anleitung genau einzuhalten

Die Proxy-Einstellung habe ich auch korrigiert.

@Chris M. : Hast Du eine Idee, was hier falsch laufen könnte?

[Chris M.]

Wie neu ist denn die Test-Version? Nicht dass Du über das Problem von viewtopic.php?f=37&t=1344 gestolpert bist...

=> Notfalls den Test-Container neu erstellen lassen (Recreate) und dabei das Image neu holen lassen (Pull latest image)

[Robosoc]

Ich habe es ja heute gerade mit Pull latest image angestoßen.

Unter Labels steht:
maintainer https://www.cometvisu.org/
org.cometvisu.cometvisubase.version -
org.cometvisu.knxd.version 0.0.5.1
org.cometvisu.pthsem.version 2.0.8
org.cometvisu.travis-build-web-url https://travis-ci.org/CometVisu/CometVi ... /623819774
org.cometvisu.travis-job-number 2916.8
org.cometvisu.travis-job-web-url https://travis-ci.org/CometVisu/CometVi ... /623819782
org.label-schema.build-date 2019-12-11T19:33:51+0000
org.label-schema.description The CometVisu visualization abstract base
org.label-schema.name CometVisu
org.label-schema.schema-version 1.0
org.label-schema.url https://www.cometvisu.org
org.label-schema.usage README.md
org.label-schema.vcs-ref 67e5e3e
org.label-schema.vcs-url https://github.com/CometVisu/Docker
org.label-schema.vendor The CometVisu project
org.label-schema.version 0.12.0-dev

Vorher hatte ich auch die 0.12.0-dev, dass hatte ich vorhin noch gesehen.

Habe aber dennoch gerade ein Recreate durchgeführt und den Pull-Schieber aktiv gelassen...hat keine Änderung gebracht.

[Robosoc]

Nur so eine Idee: Kann es sein, dass in der ARM-Version noch das alte Verzeichnis angegeben werden muss:
Volumes: Volume mapping
container: /var/www/html/config ⭢ volume: CometVisuConfig (bis einschließlich Version 0.10.2)
container: /var/www/html/resource/config ⭢ volume: CometVisuConfig (ab Version 0.11)

Ich habe sowohl vorher, als auch heute neu die untere Variante genutzt.
Die Idee habe ich nur, weil ja die Fehlermeldung im Log auf ein Verzeichnis-Thema hinweis. Ich habe aber von Portainer keine Ahnung.