Confluencer
Active member
Wer das
Alle diese Wege haben gemeinsam, dass sie die alte Container-Konfiguration übernehmen, wenn ein neuer Container auf Basis des neuen Images verwendet wird.
Docker Compose oder Portainer Stacks verursachen dieses Problem übrigens nicht.
Hier ein paar Hintergrund Informationen zur Ursache:
Bei Übernehmen der alten Container-Konfiguration erbt der neue Container ziemlich viel der Konfiguration:
- Den selbst konfigurierten Teil (über die Syno UI, Portainer, docker compose, docker run: bspw. Environment, Ports, Volumes)
- Den Default-Werten des Images (Environment, Labels, und weiteres),
- Den Container Default-Werte die Docker setzt, wenn nichts gesetzt ist
Dabei überschreiben die Default-Werte des Images die Container Default-Werte von Docker.
Die selbst konfigurierten Teil überschreiben dabei beides.
Warum ist es normalerweise kein Problem? Weil die Default-Werte für Environments zwischen dem alten und neuen Image sich nicht wesentlich verändert habe, oder nur neue dazu gekommen sind.
Warum ist es diesmal ein Problem? Weil mindestens ein Default-Wert für Environments des Images sich im Wert verändert hat und das nun zum Problem führt.
Wie kann man das beheben?
- Entweder den Container löschen und mit denselben Parametern neu anlegen mit den Ihr den alten Contaienr schon erzeugt habt (schmerzfrei bei Docker Compose, Portainer Stack,
- Händisch reparieren: dazu kann man ein `docker image inspect` (siehe unten) auf das alte und neue Image ausführen und dann vergleichen was im Bereich der Environments jetzt anders ist und dann entsprechend am neuen nicht funktionierenden Container umkonfigurieren (bspw. bei Portainer oder der Syno UI)
Beispiel zur händische Reparatur:
Alter Container (ich habe das Image per Repo:Tag angegeben, weil ich die ImageId nicht vorliegen habe):
Neuer Container (auch hier wieder Repo:Tag statt ImageId):
Man kann erkennen, dass eigentlich nur "PATH" einen geänderten Wert hat, und das die Variable "VIRTUAL_ENV" neu dazu gekommen ist.
Die neue Variable ist kein Problem, da sie auch wieder als Default-Wert vom neuen Image gezogen wird.
Die PATH Variable auf der anderen Seite ist tatsächlich ein Problem, da hier der Pfad `/lsiopy/bin` fehlt und somit die Binary "sabctools" nicht gefunden werden kann.
Es reicht also einfach die Environment-Variable
Das Vorgehen mit dem Vergleich der Environment der Images kann universell mit jedem Image angewendet werden.
linuxserver/sabnzbd verwendet und das Image von Version 3.x auf 4.x über Portainer Re-Create, Syno UI Reset, Syno Container export/import, oder Watchtower aktualisiert wird, dann kommt es zum "Missing module: sabctools" Fehler und der Container startet nicht bzw restarted permanent.Alle diese Wege haben gemeinsam, dass sie die alte Container-Konfiguration übernehmen, wenn ein neuer Container auf Basis des neuen Images verwendet wird.
Docker Compose oder Portainer Stacks verursachen dieses Problem übrigens nicht.
Hier ein paar Hintergrund Informationen zur Ursache:
Bei Übernehmen der alten Container-Konfiguration erbt der neue Container ziemlich viel der Konfiguration:
- Den selbst konfigurierten Teil (über die Syno UI, Portainer, docker compose, docker run: bspw. Environment, Ports, Volumes)
- Den Default-Werten des Images (Environment, Labels, und weiteres),
- Den Container Default-Werte die Docker setzt, wenn nichts gesetzt ist
Dabei überschreiben die Default-Werte des Images die Container Default-Werte von Docker.
Die selbst konfigurierten Teil überschreiben dabei beides.
Warum ist es normalerweise kein Problem? Weil die Default-Werte für Environments zwischen dem alten und neuen Image sich nicht wesentlich verändert habe, oder nur neue dazu gekommen sind.
Warum ist es diesmal ein Problem? Weil mindestens ein Default-Wert für Environments des Images sich im Wert verändert hat und das nun zum Problem führt.
Wie kann man das beheben?
- Entweder den Container löschen und mit denselben Parametern neu anlegen mit den Ihr den alten Contaienr schon erzeugt habt (schmerzfrei bei Docker Compose, Portainer Stack,
docker run über bash Skript, schmerzhaft bei `docker run` ohne Skript, oder zusammengeklickter Konfiguration über eine UI)- Händisch reparieren: dazu kann man ein `docker image inspect` (siehe unten) auf das alte und neue Image ausführen und dann vergleichen was im Bereich der Environments jetzt anders ist und dann entsprechend am neuen nicht funktionierenden Container umkonfigurieren (bspw. bei Portainer oder der Syno UI)
Beispiel zur händische Reparatur:
Alter Container (ich habe das Image per Repo:Tag angegeben, weil ich die ImageId nicht vorliegen habe):
Code:
me@dsm:~$ docker image inspect --format '{{json .Config.Env}}' linuxserver/sabnzbd:3.7.2 | jq
[
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PS1=$(whoami)@$(hostname):$(pwd)\\$ ",
"HOME=/config",
"TERM=xterm",
"S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0",
"S6_VERBOSITY=1",
"S6_STAGE2_HOOK=/docker-mods",
"LSIO_FIRST_PARTY=true",
"PYTHONIOENCODING=utf-8"
]
Code:
me@dsm:~$ docker image inspect --format '{{json .Config.Env}}' linuxserver/sabnzbd:4.0.1 | jq
[
"PATH=/lsiopy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PS1=$(whoami)@$(hostname):$(pwd)\\$ ",
"HOME=/config",
"TERM=xterm",
"S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0",
"S6_VERBOSITY=1",
"S6_STAGE2_HOOK=/docker-mods",
"VIRTUAL_ENV=/lsiopy",
"LSIO_FIRST_PARTY=true",
"PYTHONIOENCODING=utf-8"
]Man kann erkennen, dass eigentlich nur "PATH" einen geänderten Wert hat, und das die Variable "VIRTUAL_ENV" neu dazu gekommen ist.
Die neue Variable ist kein Problem, da sie auch wieder als Default-Wert vom neuen Image gezogen wird.
Die PATH Variable auf der anderen Seite ist tatsächlich ein Problem, da hier der Pfad `/lsiopy/bin` fehlt und somit die Binary "sabctools" nicht gefunden werden kann.
Es reicht also einfach die Environment-Variable
PATH auf den Wert /lsiopy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin zu setzen und schon startet der Container wieder.Das Vorgehen mit dem Vergleich der Environment der Images kann universell mit jedem Image angewendet werden.
