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

[Chris M.]

Das letzte mal lag die Fehlermeldung "standard_linux_init.go: exec user process caused "no such file or directory"" daran, dass eine Datei im Docker Container selbst mit den falschen Zeilenenden abgespeichert wurde. Natürlich kann es diesmal was anderes sein, aber da die Generierung des Basiscontainers zwischenzeitlich ja umgestellt wurde ist das nicht auszuschließen.

Das Volume-Mapping hätte ich erst mal ausgeschlossen, denn es geht auch komplett ohne Mapping. Dann gibt's zwar Probleme mit dem persistenten Beibehalten der Daten über ein Recreate hinweg, das ist aber gerade bei einem Test-Container nur nachrangig.

Aber: der TWS950 ist doch ein ARM basiertes System. D.h. Du müsstest doch dann 0.12.0-dev-arm verwenden, nicht?

[Robosoc]

Aber: der TWS950 ist doch ein ARM basiertes System. D.h. Du müsstest doch dann 0.12.0-dev-arm verwenden, nicht?

Ich habe definitiv cometvisu/cometvisu:testing-arm gemäß Anleitung gepulled. Wenn das Ergebnis dann 0.12.0-dev-arm sein sollte und bei mir aber zweimal 0.12.0-dev war/ist, dann scheint da eventuell irgendwas auf Github falsch verknüpft zu sein, ist das denkbar?

[Chris M.]

Denkbar: ja.
Aber nach etwas suchen scheint es so, dass hier nur die Erzeugung des org.label-schema.version nicht richtig ist, aber durchaus unter ometvisu/cometvisu:testing und cometvisu/cometvisu:testing-arm die jeweils korrekten Versionen abgelegt werden.

Ich muss mal weiter suchen.

[Chris M.]

Ich glaube ich habe es gefunden. Es war tatsächlich das alte Problem - nur dass dessen Lösung nur im 0.11-Zweig und nicht auch bei develop eingebaut wurde.
Mit https://github.com/CometVisu/CometVisu/ ... 50afc393d2 habe ich's mal nach develop übertragen.

Aktuell wird alles neu gebaut, wenn es fertig ist sollte es hoffentlich funktionieren: https://travis-ci.org/CometVisu/CometVi ... /630062382

[Robosoc]

Hallo Chris,
danke für Deine Recherche und die Rückmeldung.

Nur weil ich mit Github ("ich hab es nach develope übertragen") und travis-ci keine Erfahrung habe...Ich habe Dich jetzt so verstanden, dass man auf einem ARM-System aktuell keine lauffähige 12er Testversion bekommt, sondern bis auf Weiteres dann vermutlich auf eine 11.2er zurückgreifen muss. Korrekt?

[Robosoc]

cometvisu/cometvisu:0.11.0-arm (nutze ich aber nicht mehr)
cometvisu/cometvisu:0.11.2-arm (nutze ich jetzt als Testversion)
Laufen beide scheinbar problemlos und jetzt kann ich diese auch tatsächlich über proxy/visutest/ ansprechen.

[Robosoc]

Aber jetzt mal die Frage...das cometvisu-Thema hat ja nicht unbedingt was mit dem Absturz zu tun, sondern war ja eher ein "Nebenfund". Sollen wir die Beiträge, die sich nur um das Thema CV startet ständig neu in einen eigenen Threat verschieben? Macht denke ich sinn, oder?

Kann einer der Admins das machen (oder kann ich das selber)?
Ich denke ab Beitrag #12 ging es nur noch um das CV-Problem.

[Chris M.]

Nur weil ich mit Github ("ich hab es nach develope übertragen") und travis-ci keine Erfahrung habe...

Keine Sorge, Du brauchst davon keine Ahnung haben. Das war nur die Hintergrund-Info was der Fix war und ab wann der zur Verfügung steht. Inzwischen ist der Build durch.

Ich habe Dich jetzt so verstanden, dass man auf einem ARM-System aktuell keine lauffähige 12er Testversion bekommt, sondern bis auf Weiteres dann vermutlich auf eine 11.2er zurückgreifen muss. Korrekt?

Nein, da hast Du mich falsch verstanden. testing-arm (bzw. 0.12.0-dev-arm - ist zur Zeit ja das gleiche) sollte nun auch wieder funktionieren.

Aber jetzt mal die Frage...das cometvisu-Thema hat ja nicht unbedingt was mit dem Absturz zu tun, sondern war ja eher ein "Nebenfund". Sollen wir die Beiträge, die sich nur um das Thema CV startet ständig neu in einen eigenen Threat verschieben? Macht denke ich sinn, oder?

Ich denke, dass das CV Problem nun gelöst ist.

[Robosoc]

Jo, 12er dev funktioniert jetzt auch bei mir. Danke

[Robosoc]

Sehe gerade, dass dieses Thema als gelöst gekennzeichnet wurde. Aber ich habe es erstmal so verstanden, dass lediglich gelöst werden konnte, warum ein Container ständig neu gestartet ist, aber wenn ich ms20de und StefanW richtig verstanden habe, dann war das vermutlich nicht der Grund für den Absturz. Oder?