Se eu iniciar um processo em segundo plano e depois sair, ele continuará sendo executado?

Ao fazer isso após uma discussão prolongada com um colega de trabalho, eu realmente gostaria de um esclarecimento aqui.

Inicio um processo em segundo plano, anexando " &" à linha de comando ou parando CTRL-Ze reiniciando em segundo plano com " bg". Então eu saio.

O que acontece?

Tínhamos certeza de que deveria ter sido morto por um SIGHUP, mas isso não aconteceu; ao fazer login novamente, o processo estava em execução feliz e pstreemostrou que foi "adotado" por init.

Este é o comportamento esperado?

Mas então, se for, qual é o nohuppropósito do comando? Parece que o processo não será morto de qualquer maneira, com ou sem ...

Editar 1

Mais alguns detalhes:

• O comando foi iniciado a partir de uma sessão SSH, não a partir do console físico.
• O comando foi lançado sem nohup e / ou &; foi então suspenso CTRL-Ze retomado em segundo plano com bg.
• A sessão ssh não caiu. Houve um logout real (" exit" comando).
• O processo foi uma scpoperação de cópia de arquivo.
• Ao fazer login novamente, pstreemostrou o processo em execução e sendo filho de init.

Editar 2

Para declarar a questão com mais clareza: colocar um processo em segundo plano (usando &ou bg) fará com que seja ignorado SIGHUP, assim como o nohupcomando?

Editar 3

Tentei enviar manualmente um SIGHUPpara scp: ele saiu, por isso definitivamente não ignora o sinal.

Depois, tentei novamente iniciá-lo, colocando-o em segundo plano e efetuando logoff: ele foi "adotado" inite continuou sendo executado, e eu o encontrei lá ao fazer logon novamente.

Estou bastante confuso agora. Parece que não SIGHUPfoi enviado para o logoff.

Resposta encontrada.

Para o BASH, isso depende da huponexitopção do shell, que pode ser visualizada e / ou definida usando o shoptcomando interno.

Parece que essas opções estão desativadas por padrão, pelo menos nos sistemas baseados em RedHat.

Mais informações na página do manual BASH :

O shell sai por padrão após o recebimento de um SIGHUP. Antes de sair, um shell interativo reenvia o SIGHUP para todos os trabalhos, em execução ou interrompidos. Os trabalhos interrompidos são enviados SIGCONT para garantir que eles recebam o SIGHUP. Para impedir que o shell envie o sinal para um trabalho específico, ele deve ser removido da tabela de trabalhos com o renegado incorporado (consulte SHELL BUILTIN COMMANDS abaixo) ou marcado para não receber SIGHUP usando disown -h.

Se a opção de shell huponexit tiver sido definida com shopt, o bash enviará um SIGHUP para todas as tarefas quando um shell de logon interativo sair.

Concordo com a Warner e quero apenas acrescentar que você pode impedir que o shell envie SIGHUP com o comando "disown" incorporado. A página do manual bash contém uma boa descrição.

Você pode usar o comando nohup para iniciar o comando e redirecionar a saída para um arquivo de saída nohup. Na página do manual nohup:

nohup - run a command immune to hangups, with output to a non-tty

A outra opção é usar o comando screen . A vantagem de usar a tela é que você pode se reconectar ao processo posteriormente.

Quando você coloca um processo em segundo plano, ele ainda será o processo filho do shell que o está executando.

Todos os processos filhos em execução sob um shell recebem um SIGHUP na saída. O desempenho varia um pouco, dependendo da situação exata, detalhada detalhadamente na página de manual do bash. Outras conchas provavelmente têm descrições semelhantes.

O Apache e outros daemons geralmente recarregam a configuração no SIGHUP. Os utilitários de espaço do usuário geralmente morrem. O desempenho do aplicativo vinculado aos sinais pode ser exclusivo do aplicativo.

Qual foi o processo? O desempenho descrito na postagem anterior 1 foi preciso.

Certas funções e processos de script podem capturar sinais. enquanto loops podem fugir como loucos.

Vejo:

Sessão SSH cai - O comando continua em execução?

Editar 1 às 16:22

Na página de manual do bash:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

A pesquisa inicial 1 está mostrando que o OpenSSH provavelmente ignora o SIGHUP, talvez mais sinais.

Se você não iniciou o comando por meio de uma ferramenta como screen, então, quando a sessão terminar, todos os trabalhos / tarefas associados a essa sessão serão executados.