Container lassen sich nach System-Update nicht starten

[MartinR]

Guten Abend,
ich komme leider nicht weiter und benötige Unterstützung.
Habe ein Ubuntu-System mit den Befehlen apt update und apt upgrade gestern auf den neuesten Stand gebracht.
Leider lassen sich seitdem sämtliche Docker-Container darauf nicht mehr starten.
Die Verwaltung dieser erfolgt mit Portainer, ebenfalls als Container.
Versuche ich wie in diesem Beispiel den Container portainer zu starten erhalte ich die nachfolgende Fehlermeldung.

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: failed to add interface veth5349282 to sandbox: error setting interface "veth5349282" IPv6 to <nil>: failed to configure ipv6: failed to disable IPv6 on container's interface eth0, set env var DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1 to ignore this error: unknown
Error: failed to start containers: portainer

Leider ist mir nicht klar wie die Lösung dafür aussehen müsste.

Für hilfreiche Vorschläge wäre ich dankbar!

 

[blurrrr]

Hi,

so auf Anhieb fällt mir dazu grade auch nichts ein, aber...

set env var DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1 to ignore this error: unknown

Schon mal ausprobiert?

 

[MartinR]

Nein, bisher noch nicht.
Ich war mir nicht sicher, ob dies ein Vorschlag war, der sich nur auf das Verhalten in der sandbox auswirken würde oder eben auch auf die tatsächliche Konfiguration.
Hinzu kommt aber auch, dass ich nicht weiß, wo ich die environment variable eintragen kann.

 

[blurrrr]

Da wirst Du vermutlich nicht der einzige mit dem Problem bleiben... schau mal hier: https://docs.docker.com/engine/release-notes/26.1/:

The DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE is added as a temporary fix and will be phased out in a future major release, when the IPv6 enablement process has been improved.

Was die Umgebungsvariable angeht, Docker-Daemon stoppen, dann in der Shell einmal DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1 ausführen, Docker-Daemon wieder starten und dann nochmal den Portainer-Befehl - sollte dann theoretisch funktionieren.

Ist dann allerdings auch nur temporär... Zwecks dauerhafter Hinterlegung, kannst Du die Umgebungsvariable auch in einer neuen Zeile unter "/etc/environment" hinterlegen (danach ggf. mal das System neustarten). Ist allerdings - wie auch im o.g. Link beschrieben - nur ein temporärer Workaround, sollte also später wieder raus.

 

[Confluencer]

Kannst Du mal die Ausgabe von docker info mit uns teilen?

 

[Confluencer]

Ich denke, die Variable muss an der systemd Unit von Docker angehangen werden.
Wenn ich es richtig verstehe, sieht Docker hierfür einen Mechanismus vor:

# Verzeichnis erstellen
sudo mkdir -p /etc/systemd/system/docker.service.d

# Override für die systemd Unit von Docker erstellen
cat << EOF | sudo tee /etc/systemd/system/docker.service.d/workaround.conf
[Service]
Environment="DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1"
EOF

# Override mit berücksichtigen
sudo systemctl daemon-reload

# Docker neustarten
sudo systemctl restart docker

# Überprüfen, ob die Änderung gezogen hat
sudo systemctl show --property=Environment docker

Ich gehe davon aus, dass die Dateinamen in /etc/systemd/system/docker.service.d/ beliebig sein dürfen.

 

[MartinR]

docker info spuckt folgendes aus

Client: Docker Engine - Community
 Version:    26.1.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.14.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.27.0
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 8
  Running: 0
  Paused: 0
  Stopped: 8
 Images: 86
 Server Version: 26.1.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: e377cd56a71523140ca6ae87e30244719194a521
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
 Kernel Version: 5.10.60-qnap
 Operating System: Ubuntu 20.04.6 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 15.49GiB
 Name: ubuntu-paperless
 ID: b410c248-4f18-4919-b8ff-0809db121419
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpu shares support

Werde den von blurrrr vorgeschlagenen Workaround später noch ausprobieren.

Ich habe auf mehreren Ubuntu-Servern gestern ein Update durchgeführt. Das Problem trat danach bei allen in Bezug auf Docker und das Starten der Container auf.
Lediglich bei dem Server der den nginx Proxy-Manager als Container ausführt funktioniert alles reibungslos.

 

[Confluencer]

Das Problem ist so neu, dass wir es nicht mal drüben im offiziellen Docker Forum hatten

Es scheint nur aufzutreten, wenn die Container vor dem Update existiert haben. Da ich meine Container vor einem Update immer vollständig abräume, und die Chance auch gleich nutze die Nodes durchzustarten, hatte ich das Problem in meinem Cluster nicht.

Leg dir einfach den Override für die systemd Unit von Docker an, dann sollte es danach funktionieren.

 

[MartinR]

Werde ich machen, danke!

 

[Confluencer]

Kleine Frage noch: bist Du zufällig in einem LXC/LXD Container unterwegs?

Laut Release Notes trifft das Problem nur auf, wenn das /proc/sys/net (pseudo) Dateisystem read-only ist. Ich frage mich, wann das der Fall ist und musste an LXC Container und Konsorten denken.

 

[MartinR]

Der Vorschlag von Confluencer hat funktioniert!
Vielen Dank!

 

[MartinR]

Kleine Frage noch: bist Du zufällig in einem LXC Container unterwegs?

Laut Release Notes trifft das Problem nur auf, wenn das /proc/sys/net (pseudo) Dateisystem read-only ist. Ich frage mich, wann das der Fall ist und musste an LXC Container und Konsorten denken.

Ja bin ich

 

[Confluencer]

Da ich mir nicht erklären konnte, warum das pseudo Dateisystem überhaupt read-only gemountet sein könnte, fiel mir auf das da etwas die Capabilites einschränken muss, was zu dem beobachteten Problem führt. Das hat mich dazu gebracht nach LXD zu fragen. Vielleicht gibt es in der QNAP Container Station dazu noch irgendeine Einstellung?

 

[MartinR]

Vielleicht gibt es in der QNAP Container Station dazu noch irgendeine Einstellung?

Ich werde das noch mal überprüfen.

Nachdem ich deinen Vorschlag auch bei den anderen LXD-Containern umgesetzt habe, läuft jetzt zumindest alles wieder.
Tausend Dank!

 

[Confluencer]

Gerne!

... und nebenbei konnte ich auch noch etwas dazu lernen. Danke dafür!