Eu tenho um script bash start.sh que se parece com isso:

for thing in foo bar; do
    {
        background_processor $thing
        cleanup_on_exit $thing
    } &
done

Isso faz o que eu quero: eu corro start.sh, ele sai com o código 0 e os dois subshells são executados em segundo plano. Cada subshell é executadobackground_processor, e quando isso sai, ele é executadocleanup_on_exit. Isso funciona mesmo se eu sair do terminal do qual eu originalmente executei o start.sh (mesmo que fosse uma conexão ssh).

Então eu tentei isso:

ssh user@host "start.sh"

Isso funciona, exceto que depoisstart.sh tenha saído, ssh aparentemente também aguarda que as subshells saiam. Eu não entendo o porque. Uma vezstart.sh exits, as subshells se tornam filhos de pid 1, e eles nem sequer são designados com um tty ... então não consigo entender como eles ainda estão associados à minha conexão ssh.

Mais tarde tentei isso:

ssh -t user@host "start.sh"

Agora os processos têm uma pseudo-tty atribuída. Agora, eu acho que o ssh sai assim questart.sh sai, mas também mata os processos filhos.

Eu imaginei que os processos filhos estavam sendo enviados SIGHUP no último caso, então eu fiz isso:

ssh -t user@host "nohup start.sh"

Isso realmente funciona! Então, eu tenho uma solução para o meu problema prático, mas eu gostaria de entender as sutilezas do SIGHUP / tty aqui.

Em resumo, minhas perguntas são:

Por que o ssh (sem -t) espera pelos processos filhos mesmo depoisstart.sh saídas, mesmo que tenham pai pid 1?Por que o ssh (with -t) mata os processos filhos, aparentemente com um SIGHUP, mesmo que isso não aconteça quando eu os executar de um terminal e sair desse terminal?