90 Typische Fehlermuster

Containerfehler folgen oft wiederkehrenden Mustern. Obwohl sie sich als individuelle Symptome äußern – ein Dienst startet nicht, ein Port ist blockiert, Daten gehen verloren –, basieren sie auf einigen wenigen archetypischen Ursachenketten. Diese Muster zu erkennen, reduziert Diagnosezeit erheblich. Podman macht das besonders transparent, da Container direkt als normale Hostprozesse laufen. Statt eines Daemons, der Probleme verdeckt, offenbaren Kernel, Namespaces und Storage-Subsystem unmittelbar, was schiefgeht. Dieses Kapitel beschreibt die Fehlertypen, die in der Praxis am häufigsten auftreten, und zeigt, wie sie identifiziert werden.

90.1 Muster 1: Der Container startet nicht

Dieses Fehlermuster ist so verbreitet wie vielseitig – und dennoch strukturiert analysierbar. Typische Ursachen:

Diagnose:

  1. podman logs <ctr>
  2. podman inspect --format '{{.State.ExitCode}}' <ctr>
  3. podman inspect → Command/Entrypoint überprüfen
  4. journalctl -k → Kernel-Fehler/Denied-Messages

Ein typisches Muster:

Error: exec: "run.sh": stat run.sh: no such file or directory

oder im SELinux-Fall:

permission denied (13)

Die Technik: die Kette aus Entry-Point → Mount → Policy kontrollieren.

90.2 Muster 2: „Port nicht erreichbar“

Dieser Klassiker ist fast immer auf wenigen Ursachen zurückzuführen:

Diagnose:

podman port <ctr>
podman inspect | jq '.NetworkSettings'
ss -tulpen

Beispiel: Die Anwendung ist erreichbar aus dem Container, aber nicht vom Host. Mögliche Ursache: python -m http.server bindet standardmäßig nur an localhost.

90.3 Muster 3: Container fällt sofort wieder um (Crashloop)

Crashloops haben fast immer dieselben Gründe:

Diagnosekette:

  1. podman logs
  2. podman events --since 10m → zeigt Crash-Zeitpunkte
  3. podman inspect --format '{{.State.ExitCode}}'
  4. bei OOM: journalctl -k | grep -i oom

Wenn Logs leer sind, war es fast sicher OOM oder ein Policy-Enforcement.

90.4 Muster 4: Container kann nicht schreiben (Storageprobleme)

Ursachen sind fast immer dieselben:

Diagnose:

podman inspect <ctr> | jq '.Mounts'
df -h
df -i
ls -lZ

Fehlerbild:

permission denied

→ Aufmerksamkeit auf SELinux-Labels (container_file_t).

90.5 Muster 5: Container hat keine Netzwerkverbindung

Netzwerkfehler im Container sind oft klar strukturiert:

Diagnose:

podman exec <ctr> ip route
podman exec <ctr> ping <gateway>
podman exec <ctr> dig google.com

Wenn DNS nicht funktioniert, meistens: falsches /etc/resolv.conf im Host.

90.6 Muster 6: „Daten verschwinden“

Dieses Muster tritt auf, wenn Entwickler Volumes oder Overlay-Verhalten nicht kennen. Typische Ursachen:

Diagnose:

podman diff <ctr>
podman volume inspect

Wenn Daten nur im Upper-Layer liegen → beim Recreate verloren.

90.7 Muster 7: Ungewöhnlich hohe Latenz

Performanceprobleme entstehen oft nicht in der Anwendung, sondern in der Containerlaufzeit:

Diagnose:

podman stats
iostat -xz
podman exec <ctr> time curl http://service

Im rootless Mode sind slirp4netns-Latenzen ein typischer Grund für „gefühlt langsame“ Container.

90.8 Muster 8: „Funktioniert nur auf meinem Rechner“

Dieses Muster beruht selten auf mystischen Unterschieden, sondern auf reproduzierbaren Parametern:

Diagnose:

podman inspect
podman system info
grep <user> /etc/subuid

Insbesondere rootless Cgroups führen zu anderen Limits als rootful.

90.9 Muster 9: Speicherauslastung steigt unkontrolliert

Hier sind möglich:

Diagnose:

podman stats
ps auxf
podman diff

Ein wachsender UpperDir zeigt oft ein ungewolltes Write-Pattern.

90.10 Muster 10: Komplexe Podfehler

Pods mit mehreren Containern erzeugen eigene Fehlerszenarien:

Diagnose:

podman pod inspect
podman pod logs

Wichtig: Pod-Start bedeutet nicht Container-Start.

90.11 Muster 11: Capabilities oder Seccomp blockieren Funktionen

Viele Entwickler vergessen, dass Container nicht wie Rootprozesse agieren dürfen.

Beispiele:

Diagnose:

podman inspect | jq '.HostConfig.CapAdd'
strace -p <pid>

Fehlt CAP_NET_ADMIN, funktionieren iptables-Kommandos nicht.

90.12 Muster 12: Netzwerk- und Storagefehler durch VPN

Ein weiterer Klassiker:

Diagnose:

ip route
ip addr
systemd-resolve --status

VPN-Probleme erzeugen Containerfehler, die keinerlei Containerursache haben – ein typisches Muster.

Diese Fehlermuster sind de facto die „Big Twelve“ im Containerbereich. Wer sie erkennt, wird in der Lage sein, 90 Prozent aller Podman-Probleme innerhalb weniger Minuten systematisch zu isolieren.