qual é a diferença entre `docker stop` e` docker kill`?

116

Qual é a diferença entre docker stope docker kill?

Afaik, ambos vão parar um contêiner em execução. É isso que docker stoptenta parar o processo executado dentro do contêiner da maneira correta, enquanto docker killenvia um sinal de interrupção ? Se sim, como docker stopsaberia como parar corretamente o processo em execução. (Como isso difere de processo para processo)

docker

— Geert-Jan
fonte

113

Será que o docker stop tenta parar o processo executado dentro do contêiner da maneira correta, enquanto o docker kill envia um sinal de kill?

Basicamente, sim, a diferença é sutil, mas descrita na referência da linha de comando :

docker stop : Interrompa um contêiner em execução ( envie SIGTERM e depois SIGKILL após o período de carência ) [...] O processo principal dentro do contêiner receberá o SIGTERM e, após um período de carência, SIGKILL. [ênfase minha]
docker kill : mata um contêiner em execução ( envia SIGKILL ou sinal especificado ) [...] O processo principal dentro do contêiner será enviado SIGKILL ou qualquer sinal especificado com a opção --signal. [ênfase minha]

Portanto, stoptenta desencadear um desligamento normal enviando o sinal POSIX padrão SIGTERM, enquanto killapenas mata o processo por padrão (mas também permite enviar qualquer outro sinal):

O sinal SIGTERM é enviado para um processo para solicitar seu término. Ao contrário do sinal SIGKILL, ele pode ser capturado e interpretado ou ignorado pelo processo. Isso permite que o processo execute uma finalização agradável, liberando recursos e salvando o estado, se apropriado. Note-se que o SIGINT é quase idêntico ao SIGTERM.

Embora não seja imposto de qualquer maneira, geralmente é esperado que os processos manejem SIGTERMnormalmente e façam a coisa certa, dependendo de suas responsabilidades - isso pode falhar facilmente devido à tentativa de desligamento normal que leva mais tempo do que o período de cortesia, o que é algo a considerar se a integridade dos dados for primordial (por exemplo, para bancos de dados); veja, por exemplo, SIGTERM vs. SIGKILL do major Hayden para obter uma explicação mais detalhada:

O aplicativo pode determinar o que deseja fazer quando um SIGTERM for recebido. Embora a maioria dos aplicativos limpe seus recursos e pare, outros podem não. Um aplicativo pode ser configurado para fazer algo completamente diferente quando um SIGTERM é recebido. Além disso, se o aplicativo estiver em um estado incorreto, como aguardar a E / S do disco, talvez não seja possível atuar no sinal enviado.

— Steffen Opel
fonte

1

Portanto, se eu quisesse ter um procedimento de desligamento genérico para contêineres, teria que pegar o SIGTERM no processo de supervisor / runit?

— CMCDragonkai

Qual é a melhor prática aqui? Entendo por que usaríamos docker killmanualmente para economizar algum tempo durante o desligamento, mas em um script, não seria sempre melhor tentar um desligamento normal via docker stop? Ainda estou vendo muitos docker kills em scripts.

— Dennis

10

docker kill interromperá abruptamente o processo / programa principal do ponto de entrada

docker stop tentará pará-lo normalmente (perguntará educadamente: P)

nos dois casos, as alterações no sistema de arquivos serão mantidas (no momento da parada ou interrupção); portanto, se você docker start <container>continuar, a partir daí.

— awkwardarts
fonte

1

... mas no caso de docker killalterações no sistema de arquivos pendentes que o processo principal ainda tinha na memória será perdido, o sistema de arquivos poderá ficar danificado?

— Arjan

obviamente, como é uma parada abrupta, apenas as alterações no momento da matança serão persistidas. Qualquer coisa pendente será perdida. Meu argumento era que matar estivadores não é realmente ... matar o contêiner, está parando o processo. como quando você desligar seu computador em vez de desligar

— awkwardarts

2

Os contêineres do Docker não são VMs e o kernel permanece ativo por meio de uma interrupção. Portanto, quaisquer alterações no sistema de arquivos que atingiram o kernel serão confirmadas intactas. Não deve ser possível danificar o sistema de arquivos (no sentido fsck; o aplicativo pode não gostar de perder algumas de suas gravações). docker killé análogo a matar um processo, não a desligar o computador.

— 31718 Ian Howson

3

E além das respostas adicionadas anteriormente

correndo docker eventsdepois docker stopmostra eventos

kill (sinal 15): em que sinal 15 = SIGTERM
morrer
Pare

correndo docker eventsdepois docker killmostra eventos

kill (sinal 9): em que sinal 9 = SIGKILL
Morrer (código de saída 137)

docker stoptem um tempo limite antes de interromper o processo. O padrão é 10 segundos.

Esta tabela tem ainda mais detalhes.

— faboulaws
fonte

1

É análogo a Puxar o plugue da área de trabalho e desligar o computador

Como desligar o plug-in significa desligar o docker killcomputador com força, o caminho direto para matar o my_container, que não tenta interromper o processo normalmente primeiro.

Desligar o computador significa enviar um sinal para o SO para desligar todos os processos, onde docker stopsignifica enviar SIGTERMsinal para o contêiner em execução para interromper os processos normalmente.

— Rajat Badjatya
fonte