Por que usar "nohup &" em vez de "exec &"

Question

Eu sei que, nohup sendo um binário, pode ser alcançado a partir de qualquer shell. Mas o exec embutido provavelmente existe em cada shell.

Existe algum motivo para preferir um deles ao outro?

    

Answer 1

O que é melhor, um peixe ou uma bicicleta? nohup e exec fazem coisas diferentes.

exec substitui o shell por outro programa. Usar exec em um trabalho em segundo plano simples não é útil: exec myprogram; more stuff substitui o shell por myprogram e, portanto, não executa more stuff , diferentemente de myprogram; more stuff , que executa more stuff quando myprogram termina; mas exec myprogram & more stuff começa myprogram em segundo plano e, em seguida, executa more stuff , como myprogram & more stuff .

nohup executa o programa específico com o sinal SIGHUP ignorado. Quando um terminal é fechado, o kernel envia SIGHUP para o processo de controle naquele terminal (ou seja, o shell). O shell, por sua vez, envia o SIGHUP para todos os trabalhos em execução em segundo plano. Executar um trabalho com nohup impede que ele seja eliminado dessa forma se o terminal morrer (o que acontece, por exemplo, se você efetuou login remotamente e a conexão cair, ou se você fechar o emulador de terminal).

nohup também redireciona a saída do programa para o arquivo nohup.out . Isso evita que o programa morra porque não é capaz de gravar em sua saída ou saída de erro. Observe que nohup não redireciona a entrada. Para desconectar completamente um programa do terminal em que você o iniciou, use

nohup myprogram </dev/null >myprogram.log 2>&1 &

    

Answer 2

exec & = > executa um processo como um processo em segundo plano para que você possa continuar usando o mesmo terminal para outros trabalhos.

nohup = > evita todo o SIGHUP (sinal de terminação) e continua a execução mesmo se o terminal estiver fechado.

O processo

exec é interrompido quando um SIGHUP é recebido, mas o processo nohup continua.

    

Answer 3

O shell criado no comando exec <command> substitui o shell por <command> , nenhum novo processo, nenhum novo PID é criado. Após a conclusão de <command> normalmente, seu terminal será fechado. Ao executá-lo em segundo plano, é criada uma subshell, que então é imediatamente substituída por <command> .

O comando nohup <command> executará <command> mas importará para hangups (kill -s 1), portanto, ele não será finalizado quando o shell, o terminal a partir do qual foi iniciado, estiver fechado. Ao executá-lo em segundo plano, é criada uma subshell e o comando é executado em segundo plano, retornando ao prompt.

No script, o efeito imediato é mais ou menos o mesmo, porém, <command> é iniciado pelo seu script e o script continuará sem esperar que <command> inicie, envie a saída ou seja concluída.

    

Answer 4

Você não pode comparar nohup com exec . Quando você executa um executável com nohup , o processo não será eliminado quando você efetuar logout (sessão ssh); geralmente nohup é usado com nice para executar processos em uma prioridade mais baixa. O sinal HUP é, por convenção, o modo como um terminal avisa os processos dependentes do logout