Schermata GNU - Impossibile ricollegarsi allo schermo dopo aver perso la connessione

Stavo usando irssi sullo schermo ma ho perso la connessione. Dopo essere tornato sul server, non riesco più a collegarmi a quello schermo. screen -ls mostra che lo schermo è già collegato.

Ho provato lo schermo -D per forzare il distacco, e ha detto staccare ma lo schermo -ls dice ancora che è attaccato. Ho provato lo schermo -x e si blocca lì.

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

Cosa posso fare ora?

Se stai provando a connettere la schermata "Allegati", esegui screen -xr irssi. La '-X' maiuscola invia un comando a una delle sessioni dello schermo, l'opzione '-x' minuscola consente di riconnettersi a una sessione collegata. Ma devi ancora dare il nome della sessione poiché ce n'è più di uno.

Ho chiarito questo comportamento in passato uccidendo la shell che ha avviato la sessione dello schermo. Fondamentalmente, uccidendo tutte le istanze di bash per il mio utente che non erano di proprietà dello schermo.

Gli hai dato un nome non predefinito. Prova questo:screen -RD irssi

Puoi provare:

#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 una buona idea usare il nome completo pid.tty

screenè noto per non essere retrocompatibile tra le versioni. Se la versione di è screenstata aggiornata sul server, è possibile che non sia più possibile ricollegarsi a sessioni schermo più vecchie.

In tal caso, è possibile utilizzare il vecchio binario SCREEN per ricollegarlo (a condizione che il gestore del pacchetto di distribuzione lo abbia salvato da qualche parte), oppure interrompere del tutto la sessione.

Ho avuto un certo successo inviando il processo GNU / screen a SIGCHLD (che normalmente riceve quando una finestra è chiusa), questo lo costringe a toccare (e possibilmente ricreare) il file socket.

Si noti inoltre che esistono due modi per invocare l' screeneseguibile che differiscono solo nel caso: SCREENè il componente lato server al quale si sta tentando di riconnettersi, mentre screenè il lato client che mescola i dati tra il terminale e il lato server. Quindi potresti voler provare a uccidere la versione in minuscolo ...

Ad esempio, nel seguito puoi vedere che my screene SCREENprocessi non sono considerati genitori e figli, indicando che mi sono collegato a una sessione esistente.

# 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

Le nuove sessioni sono più simili a questa:

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

Questo mi è successo mentre stavo usando vi dove la sessione si è bloccata e mi sono disconnesso. Quando si tenta di ricollegarsi allo schermo usando screen -Arx, il processo si blocca.

Potrebbe esserci un processo figlio simile in esecuzione che fa bloccare lo schermo. Se ne ricordi uno in particolare focalizzato su quello, altrimenti per ottenere un elenco del processo figlio in esecuzione sotto lo schermo fai:

ps ux -H

Che mostrerà i processi figlio nidificati:

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

Dopo aver ucciso il processo vi che ha causato il problema in primo luogo, sono stato in grado di ricollegare lo schermo senza alcun problema. Anche uccidere qualsiasi processo precedente ricollegato allo schermo è probabilmente una buona idea. Usa solo:

kill -9 <pid>

Non so cosa stia facendo lo schermo internamente, perché vi abbia bloccato lo schermo, né perché uccidere il processo vi abbia riportato indietro il mio schermo. Mi sono imbattuto in questo problema con lo schermo in passato e avevo provato ciò che la maggior parte della gente raccomandava in questa discussione senza fortuna. Trovare questo problema è il processo figlio è l'unica cosa che ha funzionato per me e ha funzionato costantemente a questo.

screen -r 4033

screen -x 7728

killall -9 sshd

Ha funzionato per me. Avevo 3 schermi diversi e ho perso 3 connessioni ssh diverse. Dopo la riconnessione, gli schermi erano ancora collegati, ho emesso il comando sopra ... ovviamente ho perso la mia connessione attuale, ma era una nuova. Alla successiva riconnessione, ogni schermo è stato rimosso.

Nota, se sei un superutente, dovresti usare l' --useropzione per uccidere solo i tuoi demoni ssh.