Subprocessos do bash / gnome-terminal não terminam (CentOS / RHEL)

2

hoje observei algo que provavelmente tem uma explicação fácil, mas foi bastante inesperado do meu lado: Estou rodando o CentOS (e o RHEL que se comporta da mesma forma). Eu abro um bash em um terminal e inicio qualquer subprocesso como o gedit. A janela abre, tudo bem. Quando eu faço um 'ps', eu posso ver que o gedit tem o bash como seu processo pai, o qual tem o gnome-terminal como pai. Quando eu parar de bater, eu esperaria que todos os processos filhos parassem também. Mas o gedit continua rodando e o pai mudou para 1 (init)!

Eu tentei não parar o shell graciosamente, mas matá-lo com força, mesmo resultado. Ele tentou matar o terminal em vez do shell, ainda o mesmo resultado. Somente quando fecho o terminal clicando no botão X, o gedit também é fechado.

Eu não esperava esse comportamento. Começando gedit com nohup, eu não ficaria surpreso, mas mesmo sem nohup ... por que ele continua vivo?

Talvez alguém possa lançar alguma luz e saiba o que está acontecendo lá. Obrigado antecipadamente!

    
por T4X 09.10.2013 / 16:36

2 respostas

3

Programas como gedit, gvim, google-chrome e muitos outros são automaticamente colocados em segundo plano. Isso permite que você digite

gedit /home/msw/ul-answer

mapeie a nova janela e obtenha o prompt do seu shell de volta. Não é uma escolha ruim de design, e geralmente há uma opção para substituí-lo. Os comandos gedit -w e gvim --nofork não serão desanexados do terminal de controle e não retornarão seu prompt de shell.

Para um programa em segundo plano, ele se bifurca e depois o pai sai. Isso fará com que sua instância normal do gedit seja um filho do init (PPID == 1) quase que imediatamente após você digitá-lo.

Outros programas como o mplayer ou o calibre não se baseiam automaticamente porque não são digitados com freqüência ou porque gostam de despejar informações de depuração no terminal de controle.

adicionou estranheza :

Depois de gastar um pouco de tempo testando isso e vendo a saída do strace e tal, o gedit parece não estar se baseando automaticamente. O que eu disse sobre o gvim ainda vale e já passou da hora de dormir, então vou deixar isso de lado por enquanto.

    
por 09.10.2013 / 19:29
3

Quando você fecha a janela do terminal, o kernel envia um sinal SIGHUP para o bash. Bash então envia um SIGHUP para cada trabalho, então mata gedit com um SIGHUP.

Ao sair do bash digitando exit ou Ctrl + D ou matando-o com SIGKILL, o emulador de terminal percebe que seu processo filho saiu e fecha o janela. Gedit não é afetado.

    
por 10.10.2013 / 01:52