Esta é mais uma questão de gerenciamento de processos/manipulação de sinais do que uma questão de Bash. Ele apenas usa o Bash para explicar o problema.
Estou executando um script Bash no qual executo um processo em segundo plano. Este é o roteiro:
#!/bin/bash
# ...
# The background process
{
while :; do
sleep 1 && echo foo >> /path/to/some/file.txt
done
} &
# ...
exit 0
NÃO executo o script em segundo plano. Simplesmente ./script.
A opção de shell "huponexit" é habilitada usando shopt -s huponexit, portanto, quando o terminal estiver sendo fechado, espero que ele envie um sinal HUP para o Bash, que o propagará até atingir o processo em segundo plano. Se o processo em segundo plano não trapignorar o sinal, ele também será eliminado - mas isso não está acontecendo. O processo em segundo plano age como se tivesse sido disowneditado.
Este é um esquema que desenhei para ilustrar a questão. O esquema, juntamente com a descrição acima, pode estar errado, pois tenho certeza de que não entendo bem o assunto. Por favor, corrija-me sobre isso, se for realmente o caso.
Quero saber por que o processo em segundo plano não está sendo eliminado após fechar o terminal, como se tivesse sido invocado por um shell interativo como esse:
rany@~/Desktop$ while :; do sleep 1 && echo foo >> /path/to/some/file.txt; done &
Não tenho certeza, mas acho que a resposta à minha pergunta está no fato de Bash fork() ser um shell não interativo para executar o script, que pode ter um conjunto diferente de regras para controle de trabalho e manipulação de sinais.
Responder1
Então, o que a página de manual nos diz huponexit?
Se a opção shell huponexit tiver sido definida com shopt, o bash envia um SIGHUP para todos os trabalhos quando umlogin interativosaídas de shell.
EDIT: Enfatizando que é um shell LOGIN.
EDIT 2: interativo merece igual ênfase