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

No meu entendimento, os empregos são pipelines iniciados a partir de um certo shell e você pode gerenciar esses postos de trabalho ( fg, bg, Ctrl-Z) a partir desta shell. Um trabalho pode consistir em vários processos / comandos.

Minha pergunta é o que acontece com esses trabalhos quando o shell original, que sai, sai? Suponha que o huponexit não esteja definido para que os processos em segundo plano continuem em execução 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 correr sem jobsver nada, obviamente. Mas eu posso fazer ps aux | grep run.she ver esse processo em execução e também o faço para ps aux | grep grepver grep 'abc'também.

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

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 é enviado apenas se o próprio shell recebe um SIGHUP, ou seja, apenas se o terminal desaparecer (por exemplo, porque o processo do emulador de terminal morre) e não se você sair do shell normalmente (com o exitbuilt-in ou digitando Ctrl+ D). Consulte Em quais casos o SIGHUP não é enviado para um trabalho quando você se desconecta? e Existe alguma variante UNIX na qual um processo filho morre com seu pai? para mais detalhes. No bash, você pode definir a huponexitopção de enviar também SIGHUP para trabalhos em segundo plano em uma saída normal. Em ksh, bash e zsh, chamandodisownem um trabalho o remove da lista de trabalhos para os quais enviar o SIGHUP. Um processo que recebe o SIGHUP pode ignorar ou capturar o sinal e, em seguida, não morre. Usar nohupquando você executa um programa o torna imune ao SIGHUP.

Se o processo não for interrompido devido a um possível SIGHUP, ele ficará para trás. Não há mais nada relacionado a 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 os processos agrupados por grupo de processos, exibindo seu ID do grupo de processos (PGID - normalmente o ID do primeiro processo do grupo), por exemplo, ps lno Linux ou algo parecido com ps -o pid,pgid,tty,etime,commportabilidade.

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

kill -TERM -1234

Em geral, eles ainda funcionam, mas você deve usar nohup, se esqueceu ou mudou de idéia, use repudiar.

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:~$