Por que meu processo ainda está em execução depois que eu saio?

Question 1

dr:

Por que o sleepprocesso pode sobreviver quando eu saio e o terminal é fechado? Na minha opinião, tudo, exceto daemons e nohupprogramas, será eliminado durante o logout. Se sleeppuder sobreviver dessa forma, isso significa que posso usar esse método em vez do nohupcomando?

A menos que a bashinstância gerada por sshtenha a huponexitopção definida, nenhum processo será encerrado de forma alguma ao sair/logout, e quando a huponexitopção for definida, usar kill -9no shell não é uma boa alternativa para usar nohupnos processos filhos do shell; nohupnos processos filhos do shell ainda os protegerá de SIGHUPs que não vêm do shell, e mesmo quando isso não for importante nohupainda é preferível porque permite que o shell seja encerrado normalmente.

Existe bashuma opção chamada huponexit, que se definida tornará basho SIGHUP seu filho ao sair/logout;

Em interativosem login bashinstâncias, como em uma bashinstância gerada por gnome-terminal, esta opção é ignorada; esteja huponexitdefinido ou não, bashos filhos de nunca serão SIGHUPped na bashsaída;

Em interativoConecte-se bashinstâncias, como em uma bashinstância gerada por ssh, esta opção não é ignorada (no entanto, ela não está definida por padrão); se huponexitestiver definido, bashos filhos de serão SIGHUPped bashao sair/logout; se huponexitnão estiver definido, bashos filhos de 's não serão SIGHUPped bashao sair/logout;

Portanto, em geral, sair/efetuar logout de uma bashinstância de login interativa, a menos que a huponexitopção esteja definida, não tornará o shell SIGHUP seu filho, e sair/efetuar logout de uma bashinstância interativa sem login não tornará o shell SIGHUP seu filho sem considerar;

Isto é, no entanto, irrelevante neste caso: using kill -9 sleepsobreviverá independentemente, porque matar seu processo pai ( bash) não deixará chance para o último fazer issoqualquer coisapara o primeiro (ou seja, por exemplo, se a bashinstância atual era uma bashinstância de login e a huponexitopção foi definida, para SIGHUP).

Além disso, ao contrário de outros sinais (como um sinal SIGHUP enviado para bash), um sinal SIGKILL nunca é propagado para os processos filhos de um processo e, portanto, sleepnem mesmo é eliminado;

nohupinicia um processo imune aos sinais SIGHUP, o que é algo diferente; evitará que o processo seja interrompido ao receber um sinal SIGHUP, que neste caso poderia ser recebido pela bashinstância de login interativo caso a huponexitopção fosse definida e o shell fosse encerrado; portanto, tecnicamente, usar nohuppara iniciar um processo em uma bashinstância de login interativa com a huponexitopção não definida impedirá que o processo seja interrompido após a recepção de um sinal SIGHUP, mas sair/sair do shell não o SIGHUP de qualquer maneira;

Em geral, porém, quando nohupé necessário evitar que sinais SIGHUP venham do shell pai, não há razão para preferir o kill -9método on the parent ao nohupmétodo on the child; em vez disso, deveria ser o oposto.

Matar o pai usando o kill -9método não deixa uma chance para o pai sair normalmente, enquanto iniciar o filho usando o nohupmétodo permite que o pai seja encerrado por outros sinais, como SIGHUP (para dar um exemplo que faça sentido no contexto de uma criança começou a usar nohup), o que permite que ela saia normalmente.

Answer