Was ist der Unterschied zwischen "Docker Stop" und "Docker Kill"?

116

Was ist der Unterschied zwischen docker stopund docker kill?

Afaik, beide stoppen einen laufenden Container. Versucht man, docker stopden Prozessablauf im Container auf die richtige Weise zu stoppen, während docker killein Kill-Signal gesendet wird? Wenn ja, wie könnte man docker stopden laufenden Prozess korrekt stoppen? (Da dies von Prozess zu Prozess unterschiedlich ist)

docker

— Geert-Jan
quelle

113

Ist es so, dass Docker-Stopp versucht, den Prozess im Container auf die richtige Weise zu stoppen, während Docker-Kill ein Kill-Signal sendet?

Grundsätzlich ja, der Unterschied ist subtil, wird jedoch in der Befehlszeilenreferenz beschrieben :

Docker-Stopp : Stoppen Sie einen laufenden Container ( senden Sie SIGTERM und anschließend SIGKILL nach einer Nachfrist ). [...] Der Hauptprozess im Container empfängt SIGTERM und nach einer Nachfrist SIGKILL. [Hervorhebung von mir]
docker kill : Töte einen laufenden Container ( sende SIGKILL oder ein bestimmtes Signal ) [...] Der Hauptprozess innerhalb des Containers wird SIGKILL oder ein beliebiges mit der Option --signal angegebenes Signal gesendet. [Hervorhebung von mir]

So stopversucht , ein ordnungsgemäßes Herunterfahren ausgelöst wird , um den Standard zu senden POSIX - Signal SIGTERM , während killtötet nur den Prozess standardmäßig (aber erlaubt auch andere Signale zu senden):

Das SIGTERM-Signal wird an einen Prozess gesendet, um dessen Beendigung anzufordern. Im Gegensatz zum SIGKILL-Signal kann es vom Prozess abgefangen und interpretiert oder ignoriert werden. Auf diese Weise kann der Prozess eine ordnungsgemäße Beendigung durchführen, um Ressourcen freizugeben und gegebenenfalls den Status zu speichern. Es ist zu beachten, dass SIGINT nahezu identisch mit SIGTERM ist.

Obwohl dies ohnehin nicht durchgesetzt wird, wird von Prozessen im Allgemeinen erwartet, dass sie ordnungsgemäß SIGTERMablaufen und in Abhängigkeit von ihren Verantwortlichkeiten das Richtige tun. Dies kann leicht scheitern, da das ordnungsgemäße Herunterfahren länger dauert als der Kulanzzeitraum. Dies ist bei Datenintegrität zu berücksichtigen vorrangig (zB für Datenbanken); Siehe zB Major Haydens SIGTERM vs. SIGKILL für eine detailliertere Erklärung:

Die Anwendung kann bestimmen, was sie tun möchte, sobald ein SIGTERM empfangen wird. Während die meisten Anwendungen ihre Ressourcen bereinigen und stoppen, kann dies bei einigen Anwendungen nicht der Fall sein. Eine Anwendung kann so konfiguriert sein, dass sie beim Empfang eines SIGTERM etwas völlig anderes ausführt. Befindet sich die Anwendung in einem fehlerhaften Zustand, z. B. beim Warten auf Festplatten-E / A, kann sie möglicherweise nicht auf das gesendete Signal reagieren.

— Steffen Opel
quelle

1

Wenn ich also ein generisches Verfahren zum Herunterfahren von Containern haben wollte, musste ich das SIGTERM im Supervisor / Runit-Prozess abfangen.

— CMCDragonkai

Was ist die beste Vorgehensweise hier? Ich verstehe, warum wir docker killbeim Herunterfahren Zeit mit der Hand sparen, aber wäre es in einem Skript nicht immer besser, ein ordnungsgemäßes Herunterfahren über zu versuchen docker stop? Ich sehe immer noch viele docker kills in Skripten.

— Dennis

10

docker kill stoppt den Hauptzugriffspunktprozess / das Hauptzugriffspunktprogramm abrupt

docker stop werde versuchen es anmutig zu stoppen (werde höflich fragen: P)

In beiden Fällen bleiben die Änderungen am Dateisystem erhalten (zum Zeitpunkt des Stopps oder Abbruchs). Wenn Sie docker start <container>dies tun, werden die Änderungen von dort aus fortgesetzt.

— umständlich
quelle

1

... aber im Falle von docker killausstehenden Dateisystemänderungen, die der Hauptprozess noch im Speicher hatte, verloren geht, sodass das Dateisystem möglicherweise beschädigt wird?

— Arjan

Da es sich um einen abrupten Stopp handelt, werden offensichtlich nur Änderungen zum Zeitpunkt des Kills beibehalten. Alles, was noch aussteht, geht verloren. Mein Punkt war, dass Docker Kill nicht wirklich ... den Container töten, sondern den Prozess stoppen.

— Zum

2

Docker-Container sind keine VMs und der Kernel bleibt durch einen Kill am Leben. Daher werden alle Dateisystemänderungen, die den Kernel erreicht haben, unverändert übernommen. Es sollte nicht möglich sein, das Dateisystem zu beschädigen (im Sinne von fsck; die Anwendung mag es möglicherweise nicht, einige ihrer Schreibvorgänge zu verlieren). docker killist analog zum Beenden eines Prozesses und nicht zum Ausschalten des Computers.

— Ian Howson

3

Und zusätzlich zu den zuvor hinzugefügten Antworten

Laufen docker eventsnach docker stopShows Ereignisse

kill (Signal 15): wobei Signal 15 = SIGTERM ist
sterben
halt

Laufen docker eventsnach docker killShows Ereignisse

kill (Signal 9): wobei Signal 9 = SIGKILL ist
Die (Ausfahrt Code 137)

docker stophat eine Zeitüberschreitung, bevor der Prozess beendet wird. Der Standardwert beträgt 10 Sekunden.

Diese Tabelle enthält noch mehr Details.

— Faboulaws
quelle

1

Es ist analog zu Ziehen des Steckers vom Desktop und Herunterfahren des Computers

Wie das Abziehen des docker killSteckers bedeutet, dass der Computer hart ausgeschaltet ist, bedeutet dies, dass my_container direkt beendet werden kann, ohne dass zuerst versucht wird, den Prozess ordnungsgemäß herunterzufahren.

Herunterfahren des Computers bedeutet ein Signal an OS Senden für das Herunterfahren alle Prozesse , bei denen docker stopbedeutet das Senden SIGTERMSignal zu dem Laufbehälter , die Prozesse ordnungsgemäß zu stoppen.

— Rajat Badjatya
quelle