Eu estava usando o irssi na tela, mas perdi a conexão. Depois que eu voltar para o servidor, não posso mais anexar a essa tela. tela -ls mostra que a tela já está conectada.
Eu tentei screen -D para forçar a desanexar, e ele disse "desconecte", mas a tela ainda diz que está ligado. Eu tentei screen -x e ele simplesmente fica pendurado 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 posso fazer agora?
Se você estiver tentando conectar a tela 'Anexado', execute screen -xr irssi . A letra maiúscula '-X' envia um comando para uma das sessões de tela, a opção minúscula '-x' permite reconectar a uma sessão anexada. Mas você ainda precisa fornecer o nome da sessão, pois há mais de um.
Eu eliminei este comportamento no passado, matando o shell que iniciou a sessão de tela. Basicamente, matar todas as instâncias do bash para o meu usuário que não são de propriedade da tela.
Você deu um nome não padrão. Tente isto: screen -RD irssi
você pode 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. Se a versão de screen foi atualizada no servidor, é possível que você não possa mais reconectar a sessões de tela mais antigas.
Nesse caso, você pode usar o antigo binário SCREEN para reconectar (contanto que seu gerenciador de pacotes de distribuição o tenha salvado em algum lugar) ou matar a sessão completamente.
Eu tive algum sucesso enviando o processo GNU / screen para um SIGCHLD (que normalmente recebe quando uma janela é fechada), isto obriga a tocar (e possivelmente recriar) o arquivo socket.
Observe também que há duas maneiras de invocar o executável screen que diferem apenas no caso: SCREEN é o componente do servidor ao qual você está tentando se reconectar, enquanto screen é o lado do cliente que embaralha dados entre o seu terminal e o lado do servidor. Então você pode querer tentar matar a versão em minúscula ...
Por exemplo, a seguir, você pode ver que meus processos screen e SCREEN não são considerados pai e filho, indicando que eu me inscrevi em 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
Novas sessões parecem mais com isso:
19645 | \_ screen -S MySession
19646 | \_ SCREEN -S MySession
19647 | \_ bash
1485 | | \_ python
19700 | \_ bash
Isso aconteceu comigo enquanto eu estava usando vi onde a sessão congelou e eu desconectei. Ao tentar reconectar a tela usando a tela -Arx, o processo seria interrompido.
Pode haver um processo filho semelhante em execução fazendo com que a tela seja interrompida. Se você se lembrar de um em especial foco nisso, caso contrário, para obter uma lista do processo filho em execução sob sua tela, faça:
ps ux -H
O que mostrará os processos filhos 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 matar o processo do vi que causou o problema, consegui recolocar a tela sem nenhum problema. Matando todos os processos anteriores que foram reatados tela provavelmente é uma boa idéia também. Apenas use:
kill -9 <pid>
Eu não sei o que a tela está fazendo internamente, porque o vi fez com que a tela travasse, nem porque matar o processo vi trouxe minha tela de volta. Eu corri para este problema com a tela no passado e tentei o que a maioria das pessoas estava recomendando neste segmento 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 3 telas diferentes e perdi 3 conexões ssh diferentes. Depois de reconectar, as telas ainda estavam anexadas, eu emiti o comando acima ... é claro que perdi minha conexão atual, mas era nova. Na próxima reconexão, todas as telas foram separadas.
Note, se você é um superusuário, então você deve usar a opção --user para matar apenas seus daemons ssh.
Tags gnu-screen linux