28 Logs, Exec, Events

28.1 Beobachtbarkeit auf Prozessebene statt über einen Daemon

Podman verzichtet auf einen zentralen Hintergrunddienst, der sämtliche Logs aggregiert, Befehle ausführt oder Eventströme bündelt. Stattdessen wird alles direkt von den Containerprozessen und ihrem lokalen Supervisor (Conmon) abgeführt. Das Ergebnis ist ein Beobachtbarkeitsmodell, das näher am Kernel arbeitet und sich weit direkter anfühlt als das „Everything goes through the daemon“-Konzept von Docker.

Wer Systeme baut, die reproduzierbar laufen, die im Fehlerfall präzise analysiert werden müssen und deren Lifecycle klar nachvollziehbar ist, profitiert davon: Logs, Exec-Aufrufe und Events sind bei Podman keine indirekten API-Operationen, sondern integrale Bestandteile der Prozesslandschaft.

28.2 Logs: Ausgaben ohne Umwege

Containerlogs entstehen bei Podman dort, wo sie entstehen müssen – im Prozess selbst. Conmon leitet Standard-Output und Standard-Error in eine Logdatei um. Keine Blackbox, keine Filterung, keine Transformation.

28.2.1 Logquellen

1. stdout/stderr des Containerprozesses Jeder Zeilenumbruch eines Programms landet direkt in der Logdatei.

2. Conmon-Metadaten Conmon schreibt Header, Zeitstempel und Ereignisse wie Exit-Codes in dieselbe Logstruktur.

Die Standardlog-Datei liegt typischerweise hier:

/run/containers/storage/<container-id>/<container-id>-json.log

oder unter:

~/.local/share/containers/storage/

je nach Rootless/Rootful-Setup.

28.2.2 Abfrage über die CLI

podman logs myapp

Die CLI liest die Datei und gibt sie unverändert aus. Das Format basiert auf dem Docker-JSON-Logformat, um Tools kompatibel zu halten.

28.2.3 Tailen, Streaming, Optionen

Podman unterstützt klassische Tail/Follow-Semantik:

podman logs -f --tail 200 myapp

Dabei wird nicht über einen Daemon gestreamt, sondern per kontinuierlicher Dateiüberwachung. Das ist robuster: Stürzt die CLI ab, läuft der Container weiter. Startet man die CLI erneut, kann man wieder in dieselbe Datei schauen.

28.2.4 Hinweise für komplexere Anwendungen

• Dienste, die strukturiertes Logging nutzen (JSON, GELF, NDJSON), sollten weiterhin stdout/stderr nutzen.
• Rotationsmechanismus: Podman kann Logrotation über log_opts konfigurieren.
• Bei großen Ausgaben (z. B. detaillierte HTTP-Traces) wirkt sich die IO-Performance der Logdatei direkt auf den Container aus.

28.3 Exec: Befehle in bestehende Prozesse schleusen

podman exec ermöglicht es, Kommandos in einen laufenden Container einzuschleusen. Dabei geschieht nichts Magisches: Podman baut eine neue Prozesshierarchie im selben Namespace auf.

28.3.1 Was technisch geschieht

Exec verwendet setns()-Syscalls, um in die Namespaces des laufenden Containers zu wechseln – insbesondere:

• PID-Namespace (damit der neue Prozess denselben Prozessraum sieht),
• User Namespace,
• Mount Namespace,
• Network Namespace.

Anschließend wird das gewünschte Kommando mittels fork()/execve() gestartet.

Die Grundstruktur:

Dadurch gehört der Exec-Prozess logisch zum Container, obwohl er physisch vom Host aus gestartet wurde.

28.3.2 Beispiele

podman exec -it myapp sh

oder:

podman exec myapp kill -USR1 1

Exec ist ein Werkzeug zum Diagnostizieren und Steuern – aber kein Subsystem. Besonders wichtig: Exec wird nicht über einen Daemon vermittelt; wenn die CLI beendet wird, bleibt der Container unberührt.

28.3.3 Zwei praktische Hinweise

1. PID 1 bleibt PID 1 Verhalten wie Signalweiterleitung oder Shutdown-Hooks hängen von PID 1 ab. Exec ändert daran nichts.

2. Resource-Limits gelten weiterhin Ein Exec-Prozess unterliegt denselben Cgroup-Regeln wie der Container.

28.4 Events: Der Ticker der Containerwelt

Ohne Daemon braucht Podman trotzdem eine Möglichkeit, Containerzustände zu signalisieren. Dies geschieht über ein Eventsystem, das Conmon und die Engine gemeinsam erzeugen. Alle relevanten Ereignisse werden lokal persistiert und sind abrufbar.

28.4.1 Ereignistypen

Typische Events:

• create
• init
• start
• stop
• kill
• cleanup
• attach
• exec
• exec-die
• health_status: healthy/unhealthy

Diese Ereignisse reflektieren exakt, was im Prozessmodell geschieht.

28.4.2 Abfrage

podman events

oder mit Filterung:

podman events --filter event=start
podman events --filter container=myapp

Man kann Events streamen oder vergangene Einträge abrufen. Der Mechanismus eignet sich hervorragend zum Debuggen von Zustandswechseln und für automatisierte Workflows.

28.4.3 Interne Speicherung

Podman schreibt Eventinformationen in eine einfache JSON-basierte Eventlog-Datei. Tools können darauf aufsetzen, ohne einen Daemon anzuzapfen.

Ein abstrahiertes Beispiel:

{
  "Name": "start",
  "ID": "abcd1234...",
  "Image": "alpine:3.19",
  "Time": 1710000000
}

28.4.4 Typische Anwendungsfälle

• Automatisches Monitoring lokaler Entwicklungsumgebungen
• Diagnose von Fehlern, die nur beim Create/Start auftreten
• Zusätzliche Trigger für Tools wie Podman Compose
• Erkennen von Exec-Fehlern (z. B. wenn ein Init-Skript abstürzt)

Events sind damit das Äquivalent eines (dezentralen) Audit-Logs der Containerlaufzeit.

28.5 Logs, Exec, Events im Zusammenspiel

Das Dreieck aus Logs, Exec und Events bildet den operativen Werkzeugkasten für Containerdiagnose – ohne zusätzliche Schichten, ohne Hintergrunddienste, ohne Abstraktionstricks.

• Logs zeigen, was der Containerprozess wirklich tut.
• Exec ermöglicht Einblick und Intervention in laufende Instanzen.
• Events liefern Kontext zu Zustand und Lebenszyklus.

Alles basiert auf nativen Linux-Mechanismen – direkt, nachvollziehbar und frei von versteckten Kontrollinstanzen.