SIGKILL após um período de carência

Question

Eu vi muitos gerentes de processos que tentam fazer isso. Eu sabia que você deveria usar o SIGTERM apenas para matar um processo. O processo pode levar um tempo desconhecido para se limpar depois de si mesmo; em um sistema lento, pode levar alguns minutos. Eu sempre achei que a única solução era ser paciente e esperar que o programa limpasse e saísse normalmente. Se o processo não pegar SIGTERMs, então este é um bug e deve ser reportado ao mantenedor do software.

Eu vi ferramentas populares como o docker também tentando fazer isso:

Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]

Stop a running container (Send SIGTERM, and then SIGKILL after grace period)

Isso é uma prática ruim? Uma coisa que também estou curioso é como o procedimento de desligamento funciona em um sistema init estilo SystemV. Eu dei uma olhada em algumas páginas do manual e em algumas outras perguntas, mas não consegui encontrar uma resposta definitiva. Eu estou supondo que cada serviço init (terminologia?) Vê a mudança no nível de execução e executa a função "stop" adequada, conforme definido no script de inicialização. Isso é feito um a um, garantindo que cada serviço seja finalizado corretamente? O que acontece com processos não tratados por scripts de inicialização? Eu vi algumas perguntas mencionarem vagamente um período de graça sendo usado antes de SIGKILL, mas eu estava esperando que alguém pudesse elaborar ou pelo menos me apontar na direção certa. :)

Se alguém puder me ajudar a descobrir mais sobre como isso funciona com o systemd também, ficarei feliz em pesquisar e descobrir mais. Eu dei uma olhada nas páginas de manual, mas também não consegui encontrar nada definitivo.

    

Answer 1

Você pode ter seu bolo ou comê-lo. O programa quer ter o tempo que precisar (ou quiser) para reagir ao SIGTERM. O sistema (gerente de programa) quer poder terminar. Se o sistema esperar para sempre, isso permite que um programa sequestre o desligamento do sistema ao nunca responder (seja porque o programa é mal-intencionado ou porque tem bugs).

Em uma seqüência de desligamento normal, cada daemon é finalizado por meio de um script de inicialização (chame-o de script de desligamento, se desejar) fornecido pelo autor ou pelo empacotador do daemon. Dependendo do daemon, o script de inicialização pode enviar um sinal ou um desligamento mais controlado (por exemplo, gravando em um soquete). O script de inicialização pode esperar que o daemon relate que ele foi desligado satisfatoriamente ou pode ser forçado a matá-lo. Os scripts de inicialização são executados como root (eles podem chamar su para executar parte de sua tarefa como um usuário menos privilegiado); eles devem cooperar, então eles podem deixar o sistema pendurado para sempre.

Depois que os scripts de inicialização concluírem o trabalho, todos os serviços deverão ser encerrados. Qualquer processo restante deve ser sem importância ou mal-comportado. Então, neste estágio, os processos restantes são ordenados a desligar (SIGTERM), e após um período de carência (dando-lhes uma última chance de desligar) o sistema deve ser desativado para que quaisquer processos restantes sejam mortos à força (SIGKILL). p>

Pense nos scripts de inicialização como o procedimento normal de detenção - mostrar mandados, gritar um aviso etc. Um daemon que cumpra a lei deve ser encerrado neste ponto, embora os daemons tenham advogados (os scripts de init) que podem atrasar o procedimento. por quanto tempo quiserem. Quando o processo normal é concluído, os daemons restantes são considerados hostis. O sistema dispara um tiro de advertência (SIGTERM), depois de um atraso dispara para SIGKILL.