Do 'disown -h' e 'nohup' funcionam efetivamente da mesma forma?

15

disown

  • faz com que um shell não envie SIGHUP para seu trabalho de renúncia quando o shell terminar e

  • remove o trabalho rejeitado do controle de tarefa do shell.

O primeiro é o resultado do segundo? Em outras palavras, se um processo iniciado a partir de um shell for removido do controle de tarefa do shell de alguma forma, o shell não enviará SIGHUP para o processo quando o shell terminar?

disown -h ainda mantém um processo sob o controle de trabalho de um shell. Isso significa que disown -h faz um processo ainda receber SIGHUP enviado do shell, mas configura a ação de SIGHUP pelo processo para ser "ignorar"? Isso soa semelhante a nohup .

$ sleep 123 & disown -h
[1] 26103
$ jobs
[1]+  Running                 sleep 123 &
$ fg 1
sleep 123
$ ^Z
[1]+  Stopped                 sleep 125
$ bg 1
[1]+ sleep 123 &
$ exit

$ ps aux | grep sleep
t        26103  0.0  0.0  14584   824 ?        S    15:19   0:00 sleep 123

Os disown -h e nohup funcionam efetivamente da mesma forma, se desconsiderarmos a diferença deles em usar um terminal?

Obrigado.

    
por Tim 26.11.2018 / 20:48

2 respostas

19

nohup e disown -h não são exatamente a mesma coisa.

Com disown , um processo é removido da lista de trabalhos no shell interativo atual. Executar jobs após iniciar um processo de segundo plano e executar disown não mostrará esse processo como um trabalho no shell. Um trabalho rejeitado não receberá um HUP do shell quando sair (mas veja a nota no final).

Com disown -h , o trabalho não é removido da lista de tarefas, mas o shell não envia um sinal HUP para ele se ele sair (mas veja a nota no final).

O utilitário nohup ignora o sinal HUP e inicia o utilitário fornecido. O utilitário herda a máscara de sinal de nohup e, portanto, também ignorará o sinal HUP . Quando o shell é encerrado, o processo permanece como um processo filho de nohup (e nohup é representado novamente em init ).

A diferença é que o processo começou com nohup ignores HUP , independentemente de quem envia o sinal. Os processos rejeitados simplesmente não são enviados a HUP signal pelo shell , mas ainda podem ser enviados o sinal de por ex. kill -s HUP <pid> e não vai ignorar isso.

Observe que HUP é enviado apenas para os trabalhos de um shell se

  • o shell é um shell de login e a opção huponexit shell está definida ou
  • o próprio shell recebe um sinal HUP .

Bits relevantes do manual bash (minha ênfase):

SIGNALS

[...]

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.

disown [-ar] [-h] [jobspec ... | pid ... ]

Without options, remove each jobspec from the table of active jobs. [...] If the -h option is given, each jobspec is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. [...]

Relacionados:

por 26.11.2018 / 21:05
4

Eles são diferentes:

  • rejeitado remove o trabalho da tabela de trabalhos ativos. Em seguida, continua com o trabalho atual. Com -h o processo é NÃO enviado SIGHUP. Em vez disso, ele é deixado para morrer com o shell que o contém, quando recebe um SIGHUP.

  • nohup ignora o HUP. Então, qualquer coisa que tenha sido passada para o terminal pelo fechamento do processo, vai para um arquivo nohup.out .

    nohup is defined by POSIX while disown is not.

por 26.11.2018 / 21:17