86 Container Logs

Logs sind der primäre Kommunikationskanal zwischen Containerprozessen und dem Betreiber. Sie sind die niedrigschwelligste, unmittelbarste und zugleich aussagekräftigste Informationsquelle, wenn Anwendungen oder Container nicht das tun, was sie sollen. In Podman-Umgebungen kommt hinzu: Da es keinen Daemon gibt, werden Logs ohne Zwischenschicht direkt aus den Prozess- und Terminalströmen gewonnen. Container Logs sind damit ein Rohformat des tatsächlichen Prozessverhaltens – unverfälscht, unkomprimiert und genau so, wie der Prozess sie erzeugt. Genau das macht sie zu einem zentralen Werkzeug für Troubleshooting, Monitoring und Lifecycle-Diagnose.

86.1 Die Grundlagen des Container-Loggings

Ein Container besteht aus einem oder mehreren Prozessen, deren Standard-Streams (stdout, stderr) erfasst und gespeichert werden. Das Logging erfolgt:

ohne Daemon
ohne zusätzliche Formatierung
ohne Manipulation der Ausgabe

Podman speichert Logs standardmäßig im „k8s-Style“ JSON-Format:

/var/lib/containers/storage/overlay-containers/<id>/userdata/ctr.log

oder im Rootless-Kontext:

~/.local/share/containers/storage/.../ctr.log

Jeder Logeintrag enthält:

einen Zeitstempel
den Stream (stdout/stderr)
die unmodifizierte Nutzlast

Logeintrag-Beispiel:

{"time":"2025-11-23T10:12:45.123456789Z","stream":"stdout","log":"Server started\n"}

Dieses Format ist bewusst kompatibel mit Kubernetes-Tools und externen Log-Aggregatoren.

86.2 Log-Zugriff über Podman

Der Einstiegspunkt für beinahe jedes Troubleshooting:

podman logs <container>

Varianten:

--tail – nur letzte Zeilen
--since – zeitlich begrenzter Ausschnitt
--follow – Streaming wie tail -f
--timestamps – Zeitstempel einblenden

Beispiele:

podman logs --since 10m api-service
podman logs --follow webserver

Der Vorteil: Logs werden direkt aus der Logdatei gelesen – keine komplexe Abstraktion, kein Buffering durch einen Daemon.

86.3 stdout/stderr: zwei Kanäle, die oft verwechselt werden

Viele Entwickler nutzen innerhalb von Containern nur stdout, obwohl stderr für Fehlermeldungen vorgesehen ist. Podman trennt diese Kanäle korrekt:

stdout – „normale“ Applikationsausgaben
stderr – Fehlerpfad, Exceptions, Warnungen

Die Trennung ist im JSON-Log sichtbar. Bei Fehlersuche ist stderr oft der entscheidende Kanal.

86.4 Logging im Kontext von Pods

Ein Podman-Pod gruppiert mehrere Container, aber Logs sind weiterhin Container-lokal. Der Befehl:

podman pod logs <pod>

aggregiert Container-Logs lediglich sequentiell. Für tiefere Analysen ist der direkte Zugriff auf einzelne Container präziser.

Komplexer wird es bei Multi-Container-Anwendungen:

Sidecar-Container erzeugen oft mehr Logs als der Hauptprozess
ein initContainer schreibt nur beim Pod-Start – aber manchmal genau dort liegt der Fehler
Container können crashen, Pod bleibt running

Logs pro Container sind essenziell.

86.5 Exit-Codes und Log-Korrelation

Container Logs zeigen oft nur Symptome. Exit-Codes zeigen Ursachen – insbesondere bei Startfehlern.

podman inspect --format '{{.State.ExitCode}}' <container>

Typische Muster:

0 – sauber beendet
1 – allgemeiner Fehler
137 – SIGKILL (evtl. OOM)
143 – SIGTERM
139 – Segfault

Die Kombination aus Log und Exit-Code gibt eine klare Richtung für Diagnosen.

86.6 Neustarts und Log-Truncation

Podman erhält Logs containerübergreifend – auch über Restarts hinweg, solange der Container selbst nicht vollständig gelöscht wird. Je nach Logging-Driver (Standard: k8s-file) können Logs rotieren.

Rotation bedeutet:

alte Logs werden komprimiert oder entfernt
neue Logs werden angelegt

Konfigurierbar via:

/etc/containers/containers.conf

oder per CLI:

--log-opt max-size=10m
--log-opt max-file=5

Dies ist relevant bei Langläufern oder Chatty-Services.

86.7 Logging-Treiber (Log Drivers)

Podman unterstützt – ähnlich wie Docker – verschiedene Logtreiber:

k8s-file (default)
journald
none

journald ist besonders interessant für Systemintegration:

podman run --log-driver=journald ...

Die Logs erscheinen dann in:

journalctl -u libpod-<container-id>.service

Vorteil: zentrale Aggregation, Zeitstempelstandardisierung.

Nachteil: weniger portabel, nicht containerportabel wie JSON.

86.8 Integration in systemd-Units

Wenn Container über systemd betrieben werden:

stdout und stderr gehen in systemd-Journal
journalctl übernimmt gesamte Persistenz

Beispiel:

journalctl --user -u mycontainer.service

Dies ist ein häufig unterschätzter Vorteil: systemd fungiert als vollständige Logging-Pipeline für Container.

86.9 Typische Fehlerquellen in Logs

Logs zeigen oft mehr als offensichtliche Fehlermeldungen. Typische Muster:

86.9.1 Port bereits belegt

bind: address already in use

Die Ursache liegt außerhalb des Containers – Host-Port-Konflikt.

86.9.2 Fehlende Berechtigungen

permission denied

Hier ist die eigentliche Ursache meist SELinux, nicht UNIX-Permission.

86.9.3 falsche Umgebungskonfiguration

unable to find configuration file

In Multi-Stage-Builds kommt es oft zu falschen Pfadannahmen.

86.9.4 Speichergrenzen erreicht

Bei OOM:

keine Meldung im Container
Exit-Code 137
Host zeigt OOM in journalctl -k

Logs müssen also immer in Kombination mit Hostdiagnosen betrachtet werden.

86.10 Timing-Probleme

Anwendungen, die zu schnell starten (z. B. bevor ein Volume gemountet ist), erzeugen oft Startfehler, die nur Sekunden dauern. --follow oder das Lesen der frühesten Logzeilen hilft.

Podman-Startsequenzen:

Storage mounten
Namespace erstellen
Prozess starten
stdout/stderr capturen

Fehler vor Schritt 4 erscheinen oft gar nicht im Containerlog – sondern im Hostjournal.

86.11 Multi-Stage-Troubleshooting: Vom Log zur Ursache

Ein bewährtes Diagnosemodell:

86.11.1 1. Log lesen

Ist das Problem im Container selbst sichtbar?

86.11.2 2. Host-Logs prüfen

Steht der Fehler im Kerneljournal?

journalctl -k

86.11.3 3. Containerzustand prüfen

podman inspect

86.11.4 4. Prozessverhalten prüfen

podman exec
ps auxf
strace

86.11.5 5. Konfiguration und Image prüfen

CMD/ENTRYPOINT
Umgebungsvariablen
Ports
Volumes

Container Logs sind der Einstieg – aber nie die alleinige Wahrheit.

86.12 Erkennen von Nicht-Containerfehlern

Ein besonderer Vorteil von Podman: Containerfehler lassen sich oft klar von Hostfehlern trennen.

Wenn Logs im Container sauber sind, aber der Container trotzdem stoppt, liegt das Problem meist außerhalb des Containers:

zu geringe ulimit-Werte
blockierende cgroup-Limits
fehlerhafte Netzwerkplugins
kaputte Mountpoints

Container Logs sind ehrlich – wenn sie nichts sagen, steckt der Fehler häufig nicht im Nutzerlandcode.

Container Logs sind ein grundlegendes Diagnosewerkzeug, dessen Bedeutung oft unterschätzt wird. In Podman-Umgebungen reflektieren sie das unmittelbare Verhalten des Containerprozesses und bilden damit die erste, klarste und direkteste Schicht der Fehleranalyse. Logs sprechen – man muss nur zuhören.