26 Erstellen (create), Starten/Stoppen (start, stop), Löschen (rm), Kill vs. Stop: Signalverhalten

26.1 Warum Podman den Container-Lebenszyklus explizit macht

Podman folgt dem Grundsatz, dass Container Prozesse sind – keine Objekte eines Daemons. Deshalb ist der Lebenszyklus bewusst granular gestaltet: Erstellen, Starten, Stoppen und Löschen sind getrennte Schritte. Wer aus dem Docker-Ökosystem kommt, ist häufig daran gewöhnt, dass docker run mehrere dieser Schritte verdeckt. Podman dagegen zeigt jede Phase klar und nachvollziehbar. Die Steuerbarkeit steigt, und Fehler lassen sich deutlich exakter lokalisieren.

26.2 create: Der Container als „noch nicht laufende Definition“

podman create erzeugt eine Containerdefinition, aber noch keinen Prozess. Angelegt werden:

• der Container-Metadatenordner im Storage,
• das OverlayFS-Writable-Layer,
• die OCI-Konfiguration (config.json),
• Namespace- und Logging-Vorbereitungen.

Beispiel:

podman create --name app \
  -v /data:/data \
  alpine:3.19

Der Container existiert nun, läuft aber nicht. In diesem Zustand lassen sich Konfigurationen bequem prüfen:

• Mounts,
• Netzwerkparameter,
• Umgebungsvariablen,
• Device-Zuordnungen.

Fehler, die bereits beim create auftreten, liegen immer in der Konfiguration – nicht in der Laufzeit.

26.3 start: Der Moment, in dem der Prozess entsteht

Mit podman start wird der Containerprozess tatsächlich erzeugt. Intern geschieht Folgendes:

1. Die CLI ruft conmon auf.

2. Conmon ruft die Runtime (crun oder runc) auf.

3. Die Runtime erzeugt die isolierten Namespaces:

   • PID
   • IPC
   • NET
   • UTS
   • USER (bei rootless)

4. Das Root-Dateisystem wird eingebunden.

5. Die Cgroup wird eingerichtet.

6. Der definierte EntryPoint wird ausgeführt (PID 1 im Container).

7. Conmon bleibt als Supervisor bestehen.

Ablaufdiagramm:

Wenn die CLI beendet wird, läuft der Container weiter – conmon hält die Kontrolle.

26.4 stop: Der kontrollierte Shutdown

podman stop verhält sich wie klassische Prozesssteuerung unter Unix.

26.4.1 Phase 1: SIGTERM

Zuerst wird ein SIGTERM gesendet. Dadurch können Prozesse:

• Aufräumroutinen durchführen,
• Dateien schließen,
• Netzwerkverbindungen sauber beenden,
• interne Zustände speichern.

26.4.2 Phase 2: Timeout → SIGKILL

Reagiert der Prozess nicht, erfolgt nach einem definierbaren Timeout ein SIGKILL:

podman stop --timeout 10 app

SIGKILL ist nicht abfangbar und beendet sofort.

26.5 kill: kompromisslose Prozessbeendigung

podman kill sendet unmittelbar ein Signal – standardmäßig SIGKILL.

podman kill app

Eigenschaften:

• sofortige Beendigung
• keinerlei Cleanup
• Prozess wird ohne Rücksicht auf Zustand beendet

Man kann auch andere Signale senden:

podman kill --signal SIGUSR1 app

Das ist sinnvoll für Anwendungen, die über Signalschnittstellen gesteuert werden (z. B. Hot-Reload oder Reopen-Logging).

26.6 rm: Entfernen des Containers

podman rm beseitigt alle containerbezogenen Ressourcen:

• Metadaten,
• das Writable-Layer,
• Logs,
• PID-Dateien,
• temporäre Cgroup-Reste.

Beispiel:

podman rm app

Das Image bleibt bestehen. Entfernte Container können jederzeit auf Basis desselben Images neu instanziiert werden – reproduzierbar und ohne Altlasten.

Volumes werden nicht gelöscht, da sie bewusst außerhalb des Containerlebenszyklus liegen.

26.7 Kill vs. Stop: Der entscheidende Unterschied

26.7.1 Stop (SIGTERM → SIGKILL nach Timeout)

• sanft
• geeignet für Dienste
• ermöglicht Aufräumlogik
• respektiert Wartezeiten

26.7.2 Kill (SIGKILL oder anderes Signal)

• unmittelbar
• ohne Cleanup
• geeignet bei Hängern und Deadlocks

Visualisierung:

26.8 Die technische Pointe: Container verhalten sich wie Prozesse

Der Lebenszyklus folgt dem klassischen Prozessmodell:

• create → Definition
• start → Prozessstart
• run → Ausführung
• stop / kill → Signalverarbeitung
• rm → endgültige Bereinigung

Podman abstrahiert nicht – es zeigt die Mechanik. Diese Transparenz macht den Umgang mit Containern klarer, nachvollziehbarer und technisch sauber.