O que acontece com os trabalhos em segundo plano depois de sair do shell?

4

Do meu ponto de vista, empregos são pipelines ( link ) iniciados a partir de um determinado shell e você pode gerenciar esses trabalhos (fg, bg, ctrl-z) dentro deste shell. Um trabalho pode consistir em vários processos / comandos.

Minha pergunta é o que acontece com esses trabalhos quando o original, contendo shell sai? Suponha que o huponexit não esteja configurado para que os processos em segundo plano continuem sendo executados após a saída do shell.

Suponha que eu tenha feito:

run.sh | grep 'abc' &

[1] job_id

Então eu saio desse shell. Vou entrar em um novo shell e executar jobs e não vejo nada obviamente. Mas posso fazer ps aux | grep run.sh e ver esse processo em execução, além de fazer o ps aux | grep grep e ver o processo de grep 'abc' em execução também.

Existe uma maneira de obter o ID do trabalho para o pipeline completo, de modo que eu possa matá-lo de uma só vez, ou eu tenho que matar todos os processos separadamente de outro shell depois de ter saído do shell original? (Eu tentei o último e funciona, mas parece um incômodo para acompanhar todos os processos.)

    
por user2193268 23.10.2016 / 20:54

2 respostas

4

Quando o shell sai, ele pode enviar o sinal HUP para trabalhos em segundo plano, e isso pode fazer com que eles saiam. O sinal SIGHUP só é enviado se o próprio shell receber um SIGHUP, ou seja, somente se o terminal desaparecer (por exemplo, porque o processo do emulador de terminal morre) e não se você sair do shell normalmente (com exit embutido ou digitando Ctrl + D ). Consulte In quais casos o SIGHUP não é enviado para um trabalho quando você efetua logout? e Existe alguma variante do UNIX em que um processo filho morre com seu pai? para obter mais detalhes. No bash, você pode definir a opção huponexit para também enviar SIGHUP para trabalhos em segundo plano em uma saída normal. Em ksh, bash e zsh, chamar disown em um trabalho remove-o da lista de trabalhos para enviar SIGHUP. Um processo que recebe SIGHUP pode ignorar ou capturar o sinal, e então não morrerá. Usar nohup quando você executa um programa torna imune a SIGHUP.

Se o processo não for eliminado devido a um possível SIGHUP, ele fica para trás. Não há mais nada para relacioná-lo aos números de trabalho no shell.

O processo ainda pode morrer se tentar acessar o terminal, mas o terminal não existir mais. Isso depende de como o programa reage a um terminal inexistente.

Se o trabalho contiver vários processos (por exemplo, um pipeline), todos esses processos estarão em um grupo de processos . Os grupos de processos foram inventados precisamente para capturar a noção de um trabalho de shell que é composto de vários processos relacionados. Você pode ver processos agrupados por grupo de processos, exibindo seu ID de grupo de processos (PGID - normalmente, o ID do processo do primeiro processo no grupo), por exemplo, com ps l no Linux ou algo como ps -o pid,pgid,tty,etime,comm portably.

Você pode matar todos os processos em um grupo passando um argumento negativo para kill . Por exemplo, se você determinou que o PGID para o pipeline que você quer matar é 1234, então você pode matá-lo com

kill -TERM -1234
    
por 24.10.2016 / 02:35
1

Em geral, eles ainda funcionam, mas você deve usar nohup, se esqueceu ou mudou de ideia, use o disown.

mike@mike-laptop4:~$ sleep 500
^Z
[1]+  Stopped                 sleep 500
mike@mike-laptop4:~$ bg
[1]+ sleep 500 &
mike@mike-laptop4:~$ jobs
[1]+  Running                 sleep 500 &
mike@mike-laptop4:~$ disown %1
mike@mike-laptop4:~$ jobs
mike@mike-laptop4:~$ 
    
por 23.10.2016 / 22:01