85 Troubleshooting und Diagnose

Troubleshooting im Containerumfeld verlangt ein präzises Verständnis der darunterliegenden Linux-Mechanismen und des Systemverhaltens. Podman – als daemonlose Engine – bringt eine besonders transparente Fehlerdiagnostik mit sich: Alles, was passiert, ist ein normaler Hostprozess unter direkter Kontrolle des Kernels. Doch Transparenz allein löst keine Probleme; sie muss strukturiert genutzt werden. Dieses Kapitel beschreibt Methoden, Werkzeuge und Denkmodelle für eine professionelle Diagnose von Container- und Pod-Problemen in Podman-basierten Umgebungen.

85.1 Diagnose beginnt im Host – nicht im Container

Der wichtigste Grundsatz: Container sind Prozesse. Ein Fehler in einem Container ist in aller Regel ein Fehler im Prozess – oder in dessen Umgebung. Diese Perspektive unterscheidet Podman signifikant von Docker: Es gibt keinen Daemon, der Fehler verschluckt oder abstrahiert. Alle Probleme sind valide Linux-Probleme und lassen sich entsprechend untersuchen.

Ein systematischer Ablauf:

Troubleshooting verläuft entlang dieser Ebenen – vom Sichtbaren zum Systemkern.

85.2 Podman-Werkzeuge für den ersten Zugriff

Podman selbst bietet eine Reihe diagnostischer Kommandos, die häufig unterschätzt werden:

85.2.1 Inspect – der strukturelle Blick

podman inspect <container|pod>

Inspect liefert:

Inspect ist das „Röntgenbild“ der Containerstruktur. Viele Fehler liegen bereits hier offen:

85.2.2 Logs – der wichtigste Einstiegspunkt

podman logs <container>

Ob trivial oder tiefgreifend: Logs zeigen fast immer die erste Spur.

Typische Beispiele:

Logs sind nicht nur Ausgaben, sondern Bestätigungen darüber, dass der Container überhaupt gestartet wurde.

85.2.3 Events – Zeitleiste der Containerlebensdauer

podman events

Podman protokolliert:

Events ermöglichen es, Muster zu erkennen – z. B. regelmäßige Restarts durch falsche --restart-Policies oder cgroup-OOM-Ereignisse.

85.3 Netzwerkdiagnose: Namespaces anbieten sich an

Netzwerkprobleme sind die häufigste Fehlerquelle. Die Diagnose beginnt mit:

85.3.1 Podman Network Inspect

podman network inspect <network>

Hier stehen:

Wenn ein Container „niemals erreichbar“ ist, steckt fast immer ein Namespace- oder Routingproblem dahinter.

85.3.2 Netzwerksicht im Container

podman exec <container> ip addr
podman exec <container> ip route

Diese Befehle zeigen:

Ein häufiges Problem ist, dass Anwendungen auf 127.0.0.1 lauschen, obwohl sie in Containerumgebungen an 0.0.0.0 binden müssen.

85.3.3 Netzwerk-Namespace manuell betreten

nsenter --net=/proc/<PID>/ns/net

Damit wird der Netzwerk-Namespace des Containers betreten. Ideal für tiefe Fehlersuche.

85.4 Storage: übersehene Fehlerquelle

Viele Probleme entstehen durch Storage:

85.4.1 Storage-Pfade prüfen

podman inspect --format '{{.GraphDriver.Data}}' <container>

85.4.2 SELinux-Kontext prüfen

ls -lZ /pfad/zum/volume

Wenn der Kontext nicht container_file_t oder passend gelabelt ist, verweigert SELinux alle Schreiboperationen.

Ein typischer Logeintrag:

permission denied (13)

Die Ursache: SELinux – nicht fehlende UNIX-Berechtigungen.

85.5 Cgroup- und Ressourcenprobleme

Container, die „grundlos sterben“, tun dies oft wegen OOM-Killer oder Cgroup-Limits.

85.5.1 Cgroup-Nutzung anzeigen

podman stats

Zeigt:

85.5.2 Kernel-Logs auswerten

OOM-Killer-Ereignisse sieht man in:

dmesg | grep -i kill

oder im modernen Journal:

journalctl -k

Ein Container, der wegen OOM gestoppt wurde, zeigt in Podman oft nur einen „139“-Exitcode (Segfault-ähnlich).

85.6 Prozessanalysen: Container sind nur Prozesse

Ein unschlagbarer Vorteil von Podman:

Beispiele:

85.6.1 Prozessliste anzeigen

ps auxf | grep <container-id>

85.6.2 Systemcalls live verfolgen

strace -p <PID>

Dies identifiziert:

85.6.3 Ressourcenprofiling

perf top -p <PID>

Ideal für Performanceprobleme in containerisierten Anwendungen.

85.7 Diagnose von Pod-Problemen

Pod-Fehler entstehen häufig durch falsches Zusammenspiel der Container:

Diagnose:

podman pod inspect <pod>
podman pod logs <pod>

85.7.1 Lebenszyklusfehler erkennen

Ein Pod kann „running“ sein, während Container darin crashen. Podman zeigt das klar – anders als manche orchestratorbasierte Tools.

85.8 Interaktion mit systemd

Wenn Podman-Container als Dienste laufen:

systemctl --user status mycontainer.service
journalctl --user -u mycontainer.service

Häufige Ursachen:

Systemd erschwert nichts – es zeigt glasklar, was nicht startet.

85.9 Diagnose schwerer Fehler: Kernel, MAC, Seccomp

85.9.1 SELinux

Blockierte Zugriffe finden sich in:

ausearch -m avc

oder:

journalctl -t setroubleshoot

85.9.2 AppArmor

Logs:

journalctl | grep DENIED

Profile checken:

apparmor_status

85.9.3 Seccomp

Ein Container, der einen verbotenen Systemcall nutzt, stirbt sofort mit „Operation not permitted“.

Erkennen:

strace -p <PID>

wenn die letzte Ausgabe „EPERM“ oder „ENOSYS“ ist → Seccomp.

85.10 Methodisches Troubleshooting-Modell

Ein erprobtes Modell für systematische Diagnose:

  1. Symptom lokalisieren – Container? Pod? Host?
  2. Minimalfall erzeugen – kleinsten reproduzierbaren Fehler austesten
  3. Namespaces prüfen – PID, NET, MNT
  4. MAC prüfen – SELinux/AppArmor
  5. Cgroups prüfen – Ressourcen, OOM
  6. Volumes prüfen – Berechtigungen, Labels
  7. Seccomp prüfen – Systemcalls
  8. Pipeline prüfen – Build → Run → Exec → Logs
  9. Layer isolieren – Ist es Basisimage? Applikation? Orchestrator?
  10. Vergleich durchführen – Container vs. native Ausführung

Dieses Modell reduziert Diagnosezeit drastisch.

Troubleshooting in Podman-Umgebungen ist keine Kunst, sondern ein strukturierter Prozess. Die Kombination aus direkten Kernel-Interaktionen, transparenter Prozesssicht und klaren Logs ermöglicht eine Diagnosequalität, die weit über daemonbasierte Systeme hinausgeht – sofern man die richtigen Werkzeuge und Denkmodelle konsequent einsetzt.