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

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

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

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 com 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 o gedit com o nohup, eu não ficaria surpreso, mas mesmo sem o nohup... por que ele permanece vivo?

Talvez alguém possa lançar alguma luz e saiba o que está acontecendo lá. Desde já, obrigado!

Responder1

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

gedit /home/msw/ul-answer

mapeie a nova janela e recupere o prompt do shell. Não é uma má escolha de design e geralmente há uma opção para substituí-la. Os comandos gedit -we gvim --noforknão serão desconectados do terminal de controle e não devolverão o prompt do shell.

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

Outros programas como mplayer ou calibre não se colocam em segundo plano automaticamente porque não são digitados com frequência ou porque gostam de despejar informações de depuração em seu terminal de controle.

estranheza adicional:

Depois de passar um pouco de tempo testando isso e observando a saída do strace e tal, o gedit parece não estar em segundo plano automaticamente. O que eu disse sobre o gvim ainda é válido e já passou da hora de dormir, então vou deixar isso como está por enquanto.

Responder2

Quando você fecha a janela do terminal, o kernel envia umSIGHUPsinal para bater. O Bash então envia um SIGHUP para cada trabalho, matando o gedit com um SIGHUP.

Quando você sai do bash digitando exitou Ctrl+ Dou eliminando-o com SIGKILL, o emulador de terminal percebe que seu processo filho foi encerrado e fecha a janela. O Gedit não é afetado.

informação relacionada