Container Station 3.1.2.1742 Bug

Ein häufig auftretender Fehler erscheint in meinen Logs, mit folgendem Stack Trace. Claude.ai meint, es handelt sich um einen Bug im Go-Skript. Der Absturz passiert bei jeder Schnittstelle ohne IPv4-Adresse – in meinem Fall eth2 und eth3 (nicht angeschlossene physische Netzwerkkarten). Modellname: TS-673 und Firmware-Version: 5.1.9.2954 build 20241120.

Stack trace:

Wed, 03 Jun 2026 13:48:59 EDT   INFO    analytics/analytics.go:22       started analytics worker
Wed, 03 Jun 2026 13:48:59 EDT   INFO    images/update_images.go:57      started update image checker
Wed, 03 Jun 2026 13:49:21 EDT   ERROR   container-station/main.go:120   worker panic: runtime error: index out of range [0] with length 0
Wed, 03 Jun 2026 13:49:21 EDT   ERROR   container-station/main.go:121   worker panic: goroutine 63 [running]:
runtime/debug.Stack()
/usr/local/go/src/runtime/debug/stack.go:26 +0x5e
main.PreSetup.func2({0x77afc0?, 0xc000b852d0?})
/src/cmd/container-station/main.go:121 +0x8a

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:52 +0x83
panic({0x4b2460?, 0xc00045f428?})
/usr/local/go/src/runtime/panic.go:792 +0x132

/src/internal/worker/network-cache/networkconflict.go:129 +0xa94 sauron.qnapcom/core-tech/cs-team/container-station/container-station-api-server/internal/worker/network-cache.(\*NetworkConflictMonitor).Run.func2({0x0?, 0x12251f3?})
/src/internal/worker/network-cache/networkconflict.go:87 +0x1c
reflect.Value.call({0x307000?, 0xc0005156c0?, 0xc0002abbe0?}, {0x563308, 0x4}, {0xc000051648, 0x1, 0x1?})
/usr/local/go/src/reflect/value.go:584 +0xca6
reflect.Value.Call({0x307000?, 0xc0005156c0?, 0x0?}, {0xc000051648?, 0xc0000515e0?, 0x12c4650?})
/usr/local/go/src/reflect/value.go:368 +0xb9
sauron.qnapcom/core-tech/cs-team/lib/qlib/worker.(\*worker).exec(0xc0001ade00, {0x788b50, 0xc0005129b0}, {0x307000?, 0xc0005156c0?}, 0x0, 0x0)
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:197 +0x245
sauron.qnapcom/core-tech/cs-team/lib/qlib/worker.(\*worker).run(0xc0001ade00, {0xc0001f6620, 0x2, 0x2})
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:238 +0x297

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/worker/worker.go:163 +0x7b3
sauron.qnapcom/core-tech/cs-team/container-station/container-station-api-server/internal/worker/network-cache.(\*NetworkConflictMonitor).Run(0xc0002c8b40, {0x788b50, 0xc000512960})
/src/internal/worker/network-cache/networkconflict.go:96 +0x1d5
reflect.Value.call({0x2effc0?, 0xc0005155f0?, 0x13?}, {0x563308, 0x4}, {0xc0002c8b58, 0x1, 0x1?})
/usr/local/go/src/reflect/value.go:584 +0xca6
reflect.Value.Call({0x2effc0?, 0xc0005155f0?, 0x0?}, {0xc0002c8b58?, 0x0?, 0x0?})
/usr/local/go/src/reflect/value.go:368 +0xb9

/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:62 +0x5c
created by sauron.qnapcom/core-tech/cs-team/lib/qlib/pkg/routine.execGo in goroutine 58
/go/pkg/mod/sauron.qnap.com/core-tech/cs-team/lib/qlib@v0.2.66/pkg/routine/routine.go:48 +0x2dd

Hm. Zeigt dieser Pfadname etwa QNAPs Wunsch, über alle zu herrschen? Ist das der Ort, an dem dieser verfluchte Maia gelandet ist, nachdem er aus Mordor verbannt wurde?

:nerd:

Das kommt mir spanisch vor. Das war die Analyse von Claude:

  1. Produkt: Container Station 3.1.2.1742
  2. Fehler: NetworkConflictMonitor.checkNetwork() verursacht einen Panic mit index out of range [0] with length 0, wenn einem Netzwerk-Interface keine IPv4-Adresse zugewiesen ist (z. B. getrennte Netzwerkkarten, Dummy-Interfaces, etc.)
  3. Datei/Zeile: networkconflict.go:129
  4. Benötigter Fix: Vor dem Zugriff auf das Array eine Bounds-Prüfung hinzufügen: if len(addresses) == 0 { continue }
  5. Auswirkung: Der Dienst stürzt etwa alle 60 Sekunden ab und startet neu, was das QTS-Benachrichtigungsprotokoll überschwemmt.

Oder zumindest, um alle im Auge zu behalten. :wink:

Ich meine, 5.2.9 ist die aktuelle Firmware. Ich würde zumindest als erstes die 18 Monate alte Firmware aktualisieren.
Danach könnte auch ein Blick auf den Container-YAML-Code weiterhelfen.

Ich dachte, die Firmware wäre komplett aktualisiert worden, aber beim Überprüfen habe ich festgestellt, dass ich noch ein paar Patches installieren musste. Diese Updates sowie die notwendigen Software-Updates habe ich dann eingespielt, aber das Problem besteht weiterhin. Aktuell läuft Firmware 5.2.9.3499. ContainerStation ist bei 3.1.2.1742. Hoffentlich sind jetzt alle „Geh und hol einen Stein“-Aktivitäten abgeschlossen.

Wenn es hier nicht angefordert wird, würde es von QNAP verlangt werden, wenn du das Problem per Support-Ticket meldest.

So meldet man Bugs richtig. :wink:

Witzig, dass du das erwähnst. Ihr Ticketsystem hat mich sowohl online als auch in der Helpcenter-App keine Anfrage absenden lassen, und als ich im Chat versucht habe, mit einem echten Menschen zu sprechen, hat niemand geantwortet.

Was ist passiert, als du versucht hast, ein Ticket auf der QNAP-Support-Seite zu erstellen?

Es war nur eine Meldung, dass das Ticket nicht gesendet werden konnte, bitte versuche es erneut. Ich habe es ein paar Mal probiert. Ich hatte eine Textdatei angehängt, die die vom Helpdesk-Tool erstellten Details enthielt, sowie eine kleine ZIP-Datei mit Logs, die ebenfalls vom Helpdesk-Tool erstellt wurden.

Versuche, nochmal ein Ticket zu erstellen, aber füge keine Logs an, bis der Support danach fragt. Oder zumindest erst, nachdem das Ticket erfolgreich erstellt wurde. :slightly_smiling_face:

Das hat ohne die Anhänge funktioniert. Danke!

Die Lösung des Problems bestand in der Neuinstallation von ContainerStation.