Docker Compose: Down, Stop oder Kill

Ich habe docker compose stop ausgeführt und erwartet, dass der ganze Stack verschwindet. Ein paar Sekunden später listete docker compose ps immer noch jeden Container auf, und auch das Standardnetzwerk war noch da — nichts war entfernt worden, nur gestoppt. Das ist kein Bug in Compose; es ist schlicht ein anderer Befehl als down, und ich hatte die beiden bis dahin für austauschbar gehalten.

TL;DR

docker compose stop stoppt die Prozesse der Container, lässt aber Container, Netzwerk und Volumes vollständig bestehen — Sie können jederzeit wieder mit start hochfahren.
docker compose down entfernt zusätzlich die Container und das Standardnetzwerk, lässt benannte Volumes aber unangetastet.
docker compose down -v löscht außerdem jedes im Compose-File deklarierte benannte Volume — als einziger der vier Befehle mit Datenverlust-Risiko.
docker compose kill überspringt das kontrollierte Herunterfahren komplett und sendet sofort SIGKILL, ohne der Anwendung eine Chance zum Aufräumen zu geben.
stop und down senden beide zuerst SIGTERM und warten — nur kill tut das nicht.

KEY-STAT: 10 — Sekunden, die Docker nach SIGTERM wartet, bevor es bei einem nicht reagierenden stop oder down auf SIGKILL eskaliert

Was jeder Befehl tatsächlich abbaut

Befehl	Container	Standardnetzwerk	Benannte Volumes
`docker compose stop`	Gestoppt, nicht entfernt	Bleibt bestehen	Bleibt bestehen
`docker compose down`	Entfernt	Entfernt	Bleibt bestehen
`docker compose down -v`	Entfernt	Entfernt	Gelöscht
`docker compose kill`	Sofort erzwungen gestoppt, nicht entfernt	Bleibt bestehen	Bleibt bestehen

stop und down senden beide zuerst SIGTERM, nicht SIGKILL

Sowohl docker compose stop als auch docker compose down fahren den Hauptprozess eines Containers auf demselben Weg herunter: Sie senden SIGTERM, ein Signal, das ein wohlerzogener Prozess abfangen kann, um Daten zu schreiben, Verbindungen zu schließen und sauber zu beenden. Docker wartet danach — standardmäßig 10 Sekunden —, bis der Prozess tatsächlich beendet ist. Erst wenn das nach dieser Zeit nicht passiert ist, eskaliert Docker zu SIGKILL, das sich weder abfangen noch blockieren noch ignorieren lässt; der Prozess endet sofort, mitten in dem, was er gerade tat.

docker compose kill überspringt diesen letzten Schritt direkt. Es sendet beim ersten Versuch SIGKILL, ohne SIGTERM, ohne Gnadenfrist und ohne jede Chance für die Anwendung, noch etwas Laufendes zu sichern.

Der Container, der nicht stoppen wollte

Ein Hintergrund-Worker-Container auf diesem Homelab ignorierte docker compose stop komplett — der Prozess hatte gar keinen SIGTERM-Handler, das Signal bewirkte also nichts, und nach der üblichen 10-Sekunden-Wartezeit eskalierte Docker von selbst zu SIGKILL, worauf der Container trotzdem herunterfuhr, nur zehn Sekunden später als erwartet. Genau so ist der Mechanismus gedacht: stop erzwingt das Ergebnis am Ende immer, sobald die Gnadenfrist abgelaufen ist. Es lohnt sich nur dann, direkt zu docker compose kill zu greifen, wenn schon bekannt ist, dass ein Container nicht auf SIGTERM reagiert — ein hängender Prozess, ein Container in einem defekten Zustand — und man lieber die garantierte 10-Sekunden-Wartezeit überspringt, statt sie von stop per Timer neu entdecken zu lassen.

Hinweis

Ein eigener stop_signal oder stop_grace_period lässt sich pro Dienst im Compose-File setzen, falls 10 Sekunden zu kurz sind (eine Datenbank mit einem großen Checkpoint) oder unnötig lang (ein zustandsloser Dienst, der bei SIGTERM sofort beendet).

Wann kill wirklich die richtige Wahl ist

Greifen Sie zu docker compose kill statt zu stop, wenn ein Container bereits bekanntermaßen nicht reagiert — hängend, verklemmt oder ignoriert Signale aus einem vorherigen stop-Versuch — und eine weitere Gnadenfrist keinen Vorteil bringt. Für alles mit schützenswertem Zustand in Bearbeitung (eine Datenbank mitten im Schreibvorgang, eine Job-Queue mit einer aktiven Aufgabe) sollten Sie immer stop oder down bevorzugen und der SIGTERM-Gnadenfrist ihre Arbeit machen lassen; kill gibt dem Prozess null Chance zum Aufräumen.

Ein CI-Skript oder ein Automatisierungsjob ist der andere legitime Fall: Wenn ein Pipeline-Schritt einen Test-Stack so schnell wie möglich abbauen muss und nichts darin einen schützenswerten Zustand hält, ist es ein vernünftiger Tausch, die 10-Sekunden-Gnadenfrist bewusst zu überspringen und dafür einen etwas weniger sauberen Shutdown in Kauf zu nehmen — solange das eine bewusste Entscheidung ist und kein Standardgriff aus Ungeduld bei einem Stack, der tatsächlich echte Daten hält.

Warnung

kill bei einem Datenbank-Container mitten im Schreibvorgang trägt dasselbe Korruptionsrisiko wie das Ziehen des Netzsteckers — der Prozess bekommt keine Chance zu flushen. Muss ein Datenbank-Container sofort herunter, ist stop mit einer kurzen stop_grace_period sicherer als der Griff zu kill.

down -v: der einzige Befehl, der auch Volumes anfasst

Von diesen vieren kann nur down -v Daten löschen — es entfernt jedes im Compose-File deklarierte benannte Volume, zusätzlich zu allem, was down ohnehin schon tut. Das ist eine Storage-Entscheidung, keine Shutdown-Signal-Entscheidung, und verdient einen eigenen tiefen Einblick statt einer Wiederholung hier: Im Guide zu Volumes und Backups steht genau, was ein benanntes Volume enthält, wie man es sichert — und wie knapp ein down -v auf diesem selben Homelab beinahe ein Jahr an Daten gekostet hätte.

Entscheidungstabelle

Situation	Befehl
Stack pausieren, bald neu starten, schnellstmöglicher Neustart gewünscht	`docker compose stop`
Fertig mit einem Stack für den Moment, Container und Netzwerk sollen weg, Daten sollen bleiben	`docker compose down`
Wirklich fertig mit einem Stack und seinen Daten, sauberer Neuanfang gewünscht	`docker compose down -v`
Container reagiert nicht mehr, ein `stop`-Versuch ist bereits abgelaufen	`docker compose kill`
Datenbank oder alles mitten im Schreibvorgang muss herunterfahren	`docker compose stop` mit ausreichender `stop_grace_period` — niemals `kill`

Welches Netzwerk ein Container beim nächsten up wieder betritt, ist eine eigene Entscheidung, die im Docker-Compose-Networking-Guide behandelt wird, und ob er danach automatisch neu startet, hängt von der Restart-Policy ab — Shutdown-Methode, Netzwerk und Restart-Policy sind drei unabhängige Entscheidungen, keine einzige Einstellung.

Fazit

stop pausiert, down entfernt Container und Netzwerk, behält aber die Daten, down -v ist der einzige der vier Befehle, der Daten löschen kann, und kill ist der einzige, der die kontrollierte SIGTERM-Gnadenfrist komplett überspringt. Greifen Sie nur dann zu kill, wenn ein Container bereits bekanntermaßen nicht reagiert — für alles andere geben stop oder down einer Anwendung dieselbe 10-Sekunden-Chance, sauber herunterzufahren, bevor Docker das Ergebnis ohnehin erzwingt.

Häufige Fragen

Entfernt docker compose stop das Netzwerk?

Nein. docker compose stop stoppt nur die Prozesse der Container — die Container selbst, das Standardnetzwerk und alle Volumes bleiben bestehen. Verwenden Sie docker compose down, um auch Container und Netzwerk zu entfernen.

Welches Signal sendet docker compose kill?

SIGKILL, sofort, ohne vorheriges SIGTERM und ohne Gnadenfrist. Der Prozess wird auf der Stelle beendet, ohne Chance zum Aufräumen oder Sichern nicht abgeschlossener Daten.

Ist docker compose down -v sicher auszuführen?

Nur, wenn Sie sich über jedes im Compose-File deklarierte benannte Volume sicher sind — down -v löscht sie alle dauerhaft, ohne Sicherheitsabfrage. Es ist der einzige der vier Befehle stop/down/down -v/kill, der Daten verlieren kann.

Was ist der Unterschied zwischen docker compose stop und docker compose down?

stop stoppt nur die Prozesse der Container und lässt Container, Netzwerk und Volumes bestehen, bereit für einen erneuten start. down entfernt zusätzlich die Container und das Standardnetzwerk, lässt benannte Volumes aber unangetastet, sofern nicht -v hinzugefügt wird.