O que acontece com a saída de um processo que foi renegado e perdeu seu terminal?

Question

Se eu fechar o terminal virtual, onde algum processo foi iniciado, a saída vai direto para /dev/null , ou pode poluir a memória de alguma forma? De qualquer forma, posso pegar a saída para continuar lendo em algum momento depois disso?

[EDIT]: Então, o momento de rejeitar um processo efetivamente é um fim do meu poder para controlar sua saída?

Eu também notei que, se eu desisto de um processo parado, a princípio tudo parece normal: não é terminado nem mostrado em trabalhos. Mas se eu fizer logout (e eu não significa fechar o terminal, apenas sair do su , por exemplo), o processo é encerrado. Mesmo assim, um processo de renúncia de execução em segundo plano pode continuar em execução.

    

Answer 1

O fato de um processo ser "deserdado" tem apenas um significado para o shell interativo que criou esse processo. Isso significa que o shell não inclui (mais) o processo em sua tabela de jobs, e que SIGHUP não será enviado para este processo quando o shell sair. Não está realmente relacionado com as suas perguntas.

Sobre o que acontece com as saídas que são enviadas para um terminal virtual excluído: Eu mesmo fiz alguns testes e observei que /dev/pts/x dispositivos não estão acessíveis e não serão alocados novamente até que todos os descritores de arquivos que apontam para eles foram fechadas. Portanto, não vejo um motivo pelo qual as gravações em um terminal excluído sejam armazenadas. Eu acho que isso nem é definido pelo POSIX.

Sobre pegar a saída de algum processo que grava em um terminal, não acho que seja possível, mesmo quando o terminal ainda está ativo¹. Tudo o que você pode fazer é pegar a entrada direta no terminal (ou seja, pressionamentos de teclas ou pressionamentos de tecla simulados pela parte principal de um arquivo). Se os processos leiam em stdin o que está escrito em seus terminais, isso levaria a um loop self-io para a maioria dos processos.

Sobre a última observação sobre a finalização do processo, eu realmente não sei o que está acontecendo, mas suspeito comportamentos bastante estranhos com sinais (SIGTTOU, SIGTTIN, SIGHUP ou outros) relacionados ao estado de primeiro plano / plano de fundo dos grupos de processos, quando o líder da sessão sai (por exemplo, su , no caso que você mencionou).

Responda ao Editar: Não, no que diz respeito à saída, nada muda quando um processo é rejeitado: ele ainda está anexado ao seu terminal de controle (a menos que ele tenha se separado já como daemons). Você pode ver isso usando ps . No entanto, você não poderá mais usar os comandos fg / bg / jobs fornecidos pelo shell para esse processo. Isso significa que pode ser difícil alimentá-lo com a entrada do terminal (requer estar no grupo de processos em primeiro plano).

-
^{1. a menos que o processo esteja disposto ou sequestrado com algumas ferramentas de depuração (veja os comentários acima).}

    

Answer 2

Apenas para responder a essa pergunta específica:

If I close the virtual terminal, where some process was started, does the output just go straight to /dev/null, or can it pollute memory somehow?

O terminal e o (s) programa (s) conectado (s) a ele se comunicam através de um dispositivo tty, lendo-o e escrevendo-o como se fosse um arquivo. Especificamente, um terminal virtual cria uma "pseudo-tty" ("pty" para abreviar) e, em seguida, gera um shell (ou outro) processo e conecta o stdin / out / err desse processo para o pty. (Os detalhes variam de acordo com o sistema operacional).

Quando você fecha o terminal virtual, o terminal virtual fecha sua extremidade da conexão (a pty "master"). Depois disso, se o programa na outra extremidade da conexão gravar no tty, um erro será retornado e os dados não irão a lugar nenhum. Da mesma forma, se ele ler no tty, ele receberá um indicador EOF (fim do arquivo).

    

Answer 3

Para responder à parte mais interessante da sua pergunta: para alterar a saída de um programa em execução, você precisa editar seus descritores de arquivo. Isso é muito fácil de fazer com o gdb. É um hack, mas funciona.

Veja:

link

Um script auxiliar está disponível no link .

    

Answer 4

Obrigado ao comentário de Gilles, apontando-me para retty .

Parece usar algum truque sujo para se reconectar a uma (pseudo-) tty efetivamente permitindo continuar lendo a saída de um processo - não importando se ele foi renegado ou não. Então, isso parece responder a maior parte da primeira parte da minha pergunta. O segundo foi respondido por Stéphane .