12 Daemonless Prozessmodell

12.1 Ein Container ist nur ein Prozess – nichts weiter

Das daemonlose Prozessmodell von Podman basiert auf einer einfachen, fast schon altmodischen Grundannahme: Ein Container ist im Kern nur ein isolierter Linux-Prozess. Er benötigt keinen übergeordneten, privilegierten Dienst, der ihn verwaltet oder am Leben hält. Stattdessen delegiert Podman sämtliche Laufzeitverantwortung direkt an den Kernel und einen kleinen Supervisor pro Container.

Dieser Ansatz unterscheidet sich fundamental vom Docker-Modell, bei dem der Daemon (dockerd) alle Container steuert, deren Lebenszyklen überwacht und Prozesse kapselt. Podman entkoppelt diese Verantwortung vollständig.

12.2 Vom CLI-Aufruf zum laufenden Container

Wenn ein Nutzer podman run ausführt, passiert technisch erstaunlich wenig – und genau darin liegt die Stärke des Modells.

Ablauf:

Sobald der Container läuft, ist die CLI aus der Gleichung verschwunden. Es existiert kein Daemon, der danach noch Kontrolle ausübt.

12.3 Was Conmon wirklich tut

Conmon ist ein kleines C-Programm mit drei Kernaufgaben:

• start der OCI-Runtime und damit des Containerprozesses
• Überwachung der PID und Erfassung des Exit-Codes
• Weiterleitung von Logs über Pipes oder Sockets

Prozesshierarchie:

UID 1000   podman (CLI)
UID 1000      └── conmon
UID 1000            └── <EntryPoint> (Containerprozess)

Es gibt keinen globalen „Oberprozess“, dem alle Container untergeordnet sind – jeder Container hat seinen eigenen Supervisor.

12.4 Konsequenzen für Lebenszyklen und Robustheit

Ein zentraler Daemon ist eine Abhängigkeit: wenn er ausfällt, verlieren alle Container ihre Steuerung. Podman vermeidet das vollständig.

Ein Podman-Container:

• läuft weiter, wenn die CLI beendet wird
• läuft weiter, auch wenn die CLI abstürzt
• ist nicht an einen übergeordneten Dienst gekoppelt
• gehört exakt dem Nutzer, der ihn gestartet hat

Das Verhalten entspricht klassischen Unix-Prozessregeln: ein gestarteter Prozess ist unabhängig von der Shell, die ihn aufgerufen hat.

12.5 Rootless als natürlicher Nebeneffekt

Da es keinen Daemon gibt, müssen auch keine privilegierten Operationen im Hintergrund ausgeführt werden. Das ermöglicht einen Rootless-Betrieb, der funktional dem rootful Betrieb sehr nahekommt.

Ablauf – identisch für rootless und rootful:

Die gesamte Logik bleibt im Nutzerkontext.

12.6 Debugging und Transparenz im Prozessbaum

Ein Vorteil des Modells ist die vollständige Sichtbarkeit im Prozessbaum. Mit Standard-Linux-Werkzeugen lässt sich ein Container untersuchen wie jeder andere Prozess:

• ps -ef
• strace
• lsof
• perf
• htop
• systemd-cgls

Docker kapselt viele dieser Details hinter dem Daemon – Podman legt sie offen.

12.7 Kein globaler Socket, kein globaler Fehlerpfad

Der bekannte Docker-Socket (/var/run/docker.sock) ist ein privilegierter Zugriffspunkt. Wer ihn besitzt, besitzt root-Rechte. Podman eliminiert dieses Risiko. Ohne Daemon gibt es keinen solchen Socket.

Folgen:

• keine eskalierbaren Mounts in CI/CD-Pipelines
• keine zentralen Single Points of Failure
• keine Hintergrundprozesse mit permanenten Root-Rechten

Podman kommuniziert ausschließlich im jeweiligen Nutzerkontext.

12.8 Ein Prozessmodell, das sich wie Linux verhält

Das daemonlose Modell folgt einer klaren Logik:

• Podman startet den Prozess
• der Kernel isoliert ihn über Namespaces und Cgroups
• Conmon überwacht ihn
• danach ist die Engine verschwunden

Das Verhalten entspricht exakt den Mechanismen eines Linux-Systems und verzichtet vollständig auf zusätzliche Abstraktionsschichten.