Em quais casos o SIGHUP não é enviado para um trabalho quando você se desconecta?

Li uma resposta de um usuário que alegou que a execução

foo 2>&1 >& output.log &

resultaria em foocontinuar executando mesmo quando eles se desconectarem. De acordo com esse usuário, isso até funcionou em conexões SSH.

Eu realmente não acreditava nisso, pois estava com a impressão de que, no caso de desconectar do SSH ou encerrar o TTY, o shell e, portanto, seus processos receberiam um SIGHUP, fazendo com que eles terminassem. Este, sob minha suposição, foi o único motivo para o uso nohupem tais casos, ou tmux, screenet al.

Então eu olhei no manual da glibc :

Esse sinal também é usado para relatar a finalização do processo de controle em um terminal para trabalhos associados a essa sessão; essa rescisão efetivamente desconecta todos os processos da sessão do terminal de controle.

Isso parece confirmar meus pensamentos. Mas olhando mais longe, diz :

Se o processo é um líder de sessão que possui um terminal de controle, um sinal SIGHUP é enviado para cada processo no trabalho em primeiro plano, e o terminal de controle é desassociado dessa sessão.

Então, isso significa que os trabalhos colocados em segundo plano não receberão SIGHUP?

_{Para minha maior confusão, executei uma sessão interativa do Zsh, executei yes >& /dev/null &e digitei exitquando o Zsh me avisou que eu estava executando trabalhos e, depois de digitar exitpela segunda vez, me disse que havia SIGHUPed um trabalho. Fazer exatamente o mesmo no Bash deixa o trabalho em execução ...}

O Bash parece enviar o SIGHUPúnico caso receba um a SIGHUP, o que, por exemplo, ocorre quando um terminal virtual é fechado ou quando a conexão SSH é interrompida. A partir da documentação :

O shell sai por padrão após o recebimento de um SIGHUP. Antes de sair, um shell interativo reenvia o SIGHUP para todos os trabalhos, em execução ou interrompidos. Os trabalhos interrompidos são enviados SIGCONT para garantir que eles recebam o SIGHUP. Para impedir que o shell envie o sinal SIGHUP para um trabalho específico, ele deve ser removido da tabela de trabalhos com o renegado incorporado (consulte Job Control Builtins) ou marcado para não receber SIGHUP usando disown -h.

Portanto, se você digitar exitou pressionar Ctrl+ Dtodo o processo em segundo plano permanecerá, pois isso não envia um sinal de desligamento para o Bash.

Você pode forçar o Bash a avisá-lo sobre o fato de ainda haver processos em segundo plano em execução com

shopt -s checkjobs

Há uma opção para enviar a SIGHUPsaída se você estiver em um shell interativo ( veja aqui ). Mas isso não funciona na minha máquina com o Bash 4.2.25. Talvez funcione para você

shopt -s huponexit