É seguro usar o redirecionamento de saída e não o nohup?

Question

Há uma riqueza de respostas de troca de pilha em relação ao nohup, eis aqui um par de referência:
.com / questions / 137759 / why-use-nohup-rather-than-exec "> Por que usar" nohup & " em vez de "exec &"

A resposta canônica parece ser que o uso de nohup impede que o processo termine quando o terminal é fechado, portanto, comandos como este:
nohup mycommand >& mycommand_output.txt &
ainda estará em execução na próxima vez que eu fizer login, e salvará a saída para que eu possa verificá-la mais tarde.

Mas se eu salvar algumas teclas:
mycommand >& mycommand_output.txt &
também ainda está em execução quando eu fizer login pela próxima vez.

É diferente do nohup, pois posso pará-lo com kill -HUP . Quando eu fizer o login novamente, ps -x diz que o TTY do processo agora é ? , então o processo ainda não está conectado a um terminal.

Por que o processo não pára quando eu saio da casca?
Posso assumir com segurança que meus processos não terminarão se eu não usar nohup?

Caso isso seja importante, meu ambiente atual envolve o SSHing em uma máquina Debian a partir de uma máquina Ubuntu.

    

Answer 1

Can I safely assume my processes won't end if I don't use nohup

Não. Se o terminal desligar e tiver um shell interativo como líder de sessão, o shell receberá um SIGHUP e o reenviará para seus trabalhos que não foram renegados.

Se o shell sair voluntariamente, ele enviará SIGHUP para seus trabalhos se a opção huponexit estiver ativada.

Se o shell sair voluntariamente e houver trabalhos de propriedade parados, o bash os eliminará com SIGTERM (não tenho certeza se isso é um comportamento padrão).

Se o shell sair voluntariamente e houver trabalhos deserdados que estão parados, o driver do terminal os eliminará com SIGHUP (isto é, definitivamente, obrigatório pelo mandado).

Você ainda pode ser morto com o SIGHUP em vários cenários.

Dito isso, ao analisar um código-fonte nohup no link , parece mais ou menos factível em shell puro:

nohup_sh()
(
    set -e
    if [ -t 1]; then
        exec >> nohup.out || exec >> "$HOME/nohup.out"
    fi
    if [ -t 0 ]; then
        exec 0</dev/null
    fi
    if [ -t 2 ]; then
        exec 2>&1
    fi
    trap '' HUP #ignore SIGHUP (inheritable)
    set -m || : #to prevent SIGINT and SIGQUIT from being ignored
    #(probably not needed, but the nohup binary won't ignore them, unlike
    # & without set -m)

    command "$@" &
)

Você pode não precisar do material extra fora de trap '' HUP , embora o trabalho tenha SIGPIPE se tentar gravar em um terminal desconectado (que é o que os redirecionamentos evitam).

    

Answer 2

Why doesn't the process stop when I exit the shell?

Provavelmente porque você disse ao shell para disown dele. Ou talvez você não esteja usando um shell de controle de tarefas interativo como seu processo de líder de sessão.

O modelo combinado de grupos de sessões + processos com o qual o mundo se estabeleceu na década de 1980 funciona assim: Existe um processo líder de sessão . Isso é o que obtém o sinal de desligamento do terminal disciplina de linha quando o terminal é desligado. Espera-se que amplifique esse sinal, enviando ele mesmo o sinal para todos os "jobs" que ele gerou. Controle interativo controle de trabalho fará isso; a maioria dos outros programas não espera ter as responsabilidades dos líderes de sessão, e não o fará.

Usar nohup faz com que os processos naqueles "jobs" ignorem o sinal de desligamento quando o líder da sessão o envia para eles. Usar disown faz com que o shell líder da sessão se esqueça de um trabalho, de modo que ele nunca envie um sinal de desligamento para ele em primeiro lugar.

Can I safely assume my processes won't end if I don't use nohup?

Não. Se eles não tiverem sido disown ed, então eles receberão um sinal de desligamento por um processo de shell de controle de tarefas interativo líder de sessão.

Além disso: O pessoal do systemd tentou implementar um mecanismo de espaço de usuário equivalente às sessões do kernel, mas eles fizeram um pouco de orelha de porco, o que introduz mais complicações em sistemas operacionais (alguns) systemd. Na sessão do systemd, desligue em vez de enviar SIGHUP para apenas o líder da sessão, pois a disciplina de linha do kernel faz, erroneamente envia SIGTERM para todos processos, erroneamente significando shutdown do que desligar .

SIGTERM para todos os processos é, evidentemente, o que acontece, no modelo de sessão padrão + grupos de processos, no encerramento do sistema; e isso mata todos os processos, incluindo os renegados e os que ignoram o sinal de desligamento. Isso matará seus processos que não foram nemdisown ed nem nohup ed, também é claro.

Leitura adicional

• Diferença entre nohup, disown e &
• link