Tela GNU - Não é possível conectar novamente à tela após a conexão perdida

Eu estava usando o irssi na tela, mas perdi a conexão. Depois de voltar ao servidor, não consigo mais me conectar a essa tela. screen -ls mostra que a tela já está anexada.

Tentei a tela -D para forçá-lo a desanexá-lo, e ele dizia desanexar, mas a tela -ls ainda diz que está anexado. Eu tentei a tela -x e só fica lá.

[sub@server ~]$ screen -ls 
There are screens on:
 4033.poe (Detached)
 7728.irssi (Attached)
2 Sockets in /var/run/screen/S-sub.

O que eu posso fazer agora?

Se você estiver tentando conectar a tela 'Anexada', execute screen -xr irssi. O '-X' maiúsculo envia um comando para uma das sessões da tela, a opção '-x' minúscula permite que você se reconecte a uma sessão anexada. Mas você ainda precisa dar o nome da sessão, pois há mais de uma.

Eu limpei esse comportamento no passado, matando o shell que iniciou a sessão de tela. Basicamente, matando todas as instâncias do bash para o meu usuário que não eram de propriedade da tela.

Você deu um nome não padrão. Tente o seguinte:screen -RD irssi

podes tentar:

#Reattach a session and if necessary detach it first.
screen -d -r 7728.irssi  

#Reattach a session. If necessary detach and logout remotely first.
screen -D -r 7728.irssi

é sempre uma boa ideia usar o nome completo pid.tty

screené conhecido por não ser compatível com versões anteriores entre versões. Se a versão doscreen foi atualizada no servidor, pode ser possível que você não consiga anexar mais as sessões de tela mais antigas.

Nesse caso, você pode usar o binário SCREEN antigo para reconectá-lo (desde que o gerente do pacote de distribuição o tenha salvado em algum lugar) ou matar a sessão completamente.

Eu tive algum sucesso enviando ao processo GNU / screen um SIGCHLD (que normalmente recebe quando uma janela é fechada), o que o força a tocar (e possivelmente recriar) o arquivo de soquete.

Observe também que existem duas maneiras de chamar o screenexecutável que diferem apenas no caso: SCREENé o componente do lado do servidor ao qual você está tentando se reconectar, enquanto screeno lado do cliente que embaralha os dados entre o terminal e o lado do servidor. Então, você pode tentar matar a versão em minúscula ...

Por exemplo, a seguir, você pode ver que meus processos screene SCREENnão são considerados pai e filho, indicando que eu me vinculei a uma sessão existente.

# ps fao pid,command
25070 SCREEN -U
25071  \_ vim +let &t_Co=256
25073  \_ -bash
25077  \_ -bash
...
18364  \_ sshd: username [priv]
18366  |   \_ sshd: username@pts/17
18367  |       \_ -bash
  870  |           \_ screen -U -x

Sessões novas são mais ou menos assim:

19645  |  \_ screen -S MySession
19646  |      \_ SCREEN -S MySession
19647  |          \_ bash
 1485  |          |   \_ python
19700  |          \_ bash

Isso aconteceu comigo enquanto eu estava usando o vi, onde a sessão congelou e eu desconectei. Ao tentar reconectar à tela usando a tela -Arx, o processo seria interrompido.

Pode haver um processo filho semelhante em execução, causando a interrupção da tela. Se você se lembrar de um foco em particular, caso contrário, para obter uma lista do processo filho em execução na tela, faça:

ps ux -H

O que mostrará os processos filho aninhados:

zwood    28481  0.0  0.0 101148  8844 ?        Ss   Oct07   1:36 SCREEN -S mysession
zwood    28482  0.0  0.0  67436  1744 pts/2    Ss+  Oct07   0:00   /bin/bash
zwood    28515  0.0  0.0  67556  1876 pts/4    Ss+  Oct07   0:00   /bin/bash
zwood     4498  0.0  0.0  67436  1772 pts/5    Ss   Oct07   0:00   /bin/bash
zwood     2007  0.0  0.0  73604  1324 pts/5    S+   15:47   0:00     vi /home/zwood/.bashrc.custom
zwood    14670  0.0  0.0  67436  1768 pts/13   Ss+  Oct14   0:00   /bin/bash
zwood    27002  0.0  0.0  67436  1720 pts/11   Ss+  Oct20   0:00   /bin/bash
zwood    24748  0.0  0.0  67432  1712 pts/14   Ss+  Oct21   0:00   /bin/bash

Depois de finalizar o processo vi que causou o problema, consegui reconectar a tela sem nenhum problema. Matar todos os processos anteriores que foram reconectados à tela também é provavelmente uma boa idéia. Apenas use:

kill -9 <pid>

Não sei o que a tela está fazendo internamente, por que o vi causou a interrupção da tela ou por que matar o processo do vi trouxe minha tela de volta. Eu já tive esse problema com a tela no passado e tentei o que a maioria das pessoas recomendava neste tópico sem sorte. Encontrar esse processo filho problemático é a única coisa que funcionou para mim e funcionou consistentemente nisso.

screen -r 4033

screen -x 7728

killall -9 sshd

Funcionou para mim. Eu tinha três telas diferentes e perdi três conexões ssh diferentes. Depois de reconectar, as telas ainda estavam conectadas, eu emiti o comando acima ... é claro que perdi minha conexão atual, mas era nova. Na próxima reconexão, todas as telas foram desconectadas.

Observe que, se você é um superusuário, deve usar a --useropção para matar apenas seus daemons ssh.