Por que existem dois processos sequenciais de tela?

2

Eu tenho um computador rodando o Debian Wheezy (versão de tela 4.01.00devel ) e outro Debian Squeeze (versão de tela 4.00.03jw4 ) e sob ambos tela automaticamente inicia outro processo chamado screen. Por exemplo:

init(1)-+-acpid(1926)
        |-sshd(2139)---sshd(2375)---bash(2448)---screen(6649)---screen(6650)-+-bash(6651)---pstree(6751)

De acordo com o comando ps PID 6649, o comando é screen e o comando PID 6650 é SCREEN :

root@vserver:~# ps -f -p 6650
UID        PID  PPID  C STIME TTY          TIME CMD
root      6650  6649  0 11:26 ?        00:00:00 SCREEN
root@vserver:~# 

Por que o screen se comporta assim?

    
por Martin 07.08.2014 / 13:31

2 respostas

2

O nível externo screen (PID 6649) conecta-se ao terminal de onde você iniciou e é finalizado quando você desanexar ( Ctrl + a , d ).

O interior screen (PID 6650) não está conectado a esse terminal, mas controla seu próprio dispositivo pseudo-terminal (pty), ao qual o bash iniciado a partir dele é conectado .

O que acontece é que quando você digita algo no terminal externo, o% externo screen o recebe, envia-o por um soquete para a tela interna, e esse, por sua vez, encaminha a entrada para o arquivo que ele controla. atinge bash (ou qualquer outro programa iniciado a partir do bash, e controlado através do mesmo pty). A saída do bash (ou qualquer programa iniciado a partir dele) será enviada para o arquivo interno screen , o que faz com que o screen interno o envie através do soquete para o% externoscreen, que finalmente o envia ao terminal você iniciou screen de (que no seu caso é novamente um arquivo criado por ssh ). Note que o socket é controlado pelo inner screen , que permite desanexar e voltar a ligar (veja abaixo).

Se você desanexar a instância screen , o que acontece é que o screen interno, e com ele o controle, continua a existir. É por isso que os processos que se conectam a ele sobreviverão, mesmo se eles tentarem fazer E / S. No entanto, o% externo screen terminará, interrompendo assim a conexão com o terminal externo. Você pode agora, por exemplo, encerrar a sessão ssh , e assim destruir o arquivo correspondente, e isso não afetará o screen interno nem os programas iniciados por ele, já que eles se comunicam através de seu próprio dispositivo.

Se você fizer login novamente (criando outro pty) e, em seguida, chamar screen -r , a instância screen recém-criada será conectada ao terminal do qual você iniciou (que é completamente separado daquele da primeira instância foi iniciado a partir de, desde que você destruiu isso) e, em seguida, use o soquete fornecido pela instância screen interna para reconectar-se com o screen interno, que enviará o estado atual de seu próprio arquivo para o "externo" screen para exibir novamente; depois, a mesma linha de transmissão de E / S acontece com a instância externa screen anterior.

Se você agora fizer um pstree , encontrará duas linhas com screen : uma começando em sshd e terminando na nova instância "outer" screen , e um começando com a instância "%"screen "interna" que agora não tem mais um pai desde que foi terminado quando você desanexou o screen .

Então, resumindo:

  • A tela "externa" (PID 6649) conecta-se ao terminal com o qual você está interagindo (no seu caso, o arquivo configurado por ssh ) e só dura enquanto você estiver conectado ao screen instância.
  • A tela "interna" (PID 6650) fornece um arquivo separado para os programas que você inicia na tela e também fornece o soquete usado para comunicar o estado do terminal entre a instância externa e interna screen . Vive até você terminar screen (ao invés de separar).
  • A separação é necessária para permitir que os programas controlados sobrevivam à morte do material externo (sendo conectado a um objeto diferente que, junto com seu processo de controle - o interior screen - sobrevive ao desligamento do terminal externo), bem como para reconectar (tendo o screen interno sobrevivente fornecendo um soquete ao qual novas instâncias de screen podem se conectar).
por 07.08.2014 / 18:02
0

Eu acho que a razão para o segundo processo (aquele com PID 6650 na sua amostra) é fechar a conexão tty (stdin, stdout e stderr), então você pode sair. logg de volta mais tarde uma retomada onwship de tela.

Como você pode ver, o PID 6650 não está conectado a um tty (a coluna TTY diz '?').

    
por 07.08.2014 / 14:58

Tags