docker stop non è docker kill
Il 28 ottobre 2026 la reference di docker stop descrive SIGTERM e, dopo un tempo di grazia, SIGKILL. Senza un default sul container sono 10 secondi su Linux e 30 su Windows. docker kill manda SIGKILL subito, salvo un altro --signal.
In questa guida (6)
Il 28 ottobre 2026 docker stop non è docker kill. Sulla documentazione di Docker, docker container stop manda SIGTERM al processo principale e, dopo un tempo di grazia, SIGKILL. Se il container non ha un default suo, quel tempo è 10 secondi sui container Linux e 30 sui container Windows. docker container kill, sulla sua pagina, manda SIGKILL subito, salvo un altro segnale passato con --signal. Un segnale diverso da SIGKILL può non fermare il container. Non è il Type=simple di systemd e non è Restart=on-failure.
In breve: stop aspetta, poi forza. Kill, di default, forza subito. --timeout -1 su stop toglie il limite e il daemon aspetta senza scadenza. Non ho eseguito i comandi su un host di produzione: ho letto le due pagine della reference il 28 ottobre 2026.
SIGTERM e poi SIGKILL
La pagina docker container stop dice che il processo principale dentro il container riceve SIGTERM e, dopo un periodo di grazia, SIGKILL. L’alias del comando è docker stop. Il primo segnale si cambia con l’istruzione STOPSIGNAL nel Dockerfile, oppure con --stop-signal su docker run e docker create. Più sotto, la stessa pagina precisa: se per il container non è configurato un segnale, il default è SIGTERM. SIGKILL resta il segnale di chiusura forzata allo scadere del tempo. Cambiare il primo segnale non cancella il secondo.
La pagina rimanda a signal(7) per l’elenco dei segnali. Non ho incollato qui il manuale del kernel. Quello che serve per il comando è scritto nella reference: il primo segnale è configurabile, l’ultimo della sequenza di stop è SIGKILL.
10 secondi non sono 30
Il flag -t / --timeout è il numero di secondi da aspettare dopo il segnale, prima del SIGKILL. Il default di quel tempo si imposta con --stop-timeout quando si crea il container. Se il container non ha un default, decide il daemon: 10 secondi per i container Linux, 30 secondi per i container Windows. È la frase della sezione «Stop container with timeout», non una stima.
| Comando, docs lette il 28 ottobre 2026 | Segnale di partenza | Attesa | Se il processo non esce |
|---|---|---|---|
docker stop, container Linux senza --stop-timeout | SIGTERM, se non c’è uno STOPSIGNAL | 10 secondi | SIGKILL |
docker stop, container Windows senza default | SIGTERM, se non c’è uno STOPSIGNAL | 30 secondi | SIGKILL |
docker stop -t -1 | Il segnale configurato | Nessun timeout: il daemon aspetta senza scadenza | La pagina non descrive un SIGKILL successivo |
docker kill | SIGKILL, salvo --signal | La pagina di kill non descrive un periodo di grazia | SIGKILL, di default, termina il container |
Un timeout copiato da un esempio Windows, 30 secondi, non è il default Linux. Un timeout copiato da Linux, 10 secondi, non è il default Windows. Se l’immagine è nata con --stop-timeout, vale quello, non la cifra del daemon.
docker kill può non chiudere il container
La pagina docker container kill, alias docker kill, dice che il sottocomando uccide uno o più container. Il processo principale riceve SIGKILL, che è il default, oppure il segnale di --signal. Il container si indica con ID, prefisso di ID o nome. La stessa pagina avverte che SIGKILL termina il container, mentre il segnale passato con --signal può non essere terminale. L’esempio è SIGHUP: nella maggior parte dei casi non è terminale, e il container continua a girare dopo averlo ricevuto.
Il nome del comando, kill, non garantisce la chiusura se si cambia segnale. La pagina di kill, nella descrizione letta oggi, non scrive i 10 secondi e non scrive i 30. Non descrive la sequenza SIGTERM e poi SIGKILL. Quella sequenza sta sulla pagina di stop.
-1 non è zero
Su stop, --timeout -1 non è un timeout di un secondo e non è un timeout di zero secondi. La reference dice che non si applica alcun timeout e che il daemon aspetta senza scadenza che il container esca. È il caso in cui la chiusura forzata descritta per il timeout positivo non scatta. Zero, sulla stessa frase, non compare. Non lo invento come sinonimo di -1.
Un processo che ignora SIGTERM, con il default Linux, ha dieci secondi e poi riceve SIGKILL. Lo stesso processo, con -t -1, resta appeso all’attesa del daemon. Sono due modi diversi di «fermare» un container, e solo uno dei due ha una fine scritta nella pagina.
Errori da evitare
Usare
docker killquando serve lasciare al processo il tempo di chiudere i file. La pagina di kill non descrive un periodo di grazia. Quello sta sudocker stop.Credere che
docker stopaspetti sempre 10 secondi. Dieci è il default del daemon per i container Linux senza--stop-timeout. Windows, sulla stessa frase, è 30. Un container creato con un altro--stop-timeoutusa il suo.Passare
--signal SIGHUPadocker kille dare il container per spento. La reference dice che SIGHUP, nella maggior parte dei casi, non è terminale.Leggere
--timeout -1come «ferma subito». La pagina dice l’opposto: nessuna scadenza.Cambiare solo
STOPSIGNALe credere di avere disattivato SIGKILL. Su stop, SIGKILL resta il segnale allo scadere del tempo.Confondere questo timeout con
Restart=di systemd. Sono due meccanismi, su due pagine diverse.
In sintesi
Il 28 ottobre 2026 la reference di docker stop descrive SIGTERM, poi un tempo di grazia, poi SIGKILL. Senza un default sul container, il daemon usa 10 secondi su Linux e 30 su Windows. --timeout -1 toglie la scadenza. STOPSIGNAL e --stop-signal cambiano il primo segnale, non il SIGKILL finale. docker kill manda SIGKILL subito, oppure il segnale di --signal, che può non chiudere il container, come nel caso di SIGHUP citato dalla stessa pagina.
Foto di copertina: Rsparks3, «Data center roof», Wikimedia Commons, CC0. La descrizione del file parla di tetto di un data center, torri di raffreddamento e generatori di backup. Non è un log di Docker e non è un timeout di 10 secondi.
