Impossible de récupérer l'écran détaché pour reprendre


11

J'utilise du mastic et ma connexion sans fil n'est pas fiable, j'utilise donc l'écran pour continuer mon travail. Souvent, je me déconnecte, puis je ne peux pas rattacher mon écran. Je vais courir screen -D -RRet il restera là indéfiniment. J'ai essayé ctrl+zde récupérer ma console, puis ps aux | grep screenpuis kill -9pour tous les résultats, puis à screen -D -RRnouveau mais j'obtiens les mêmes résultats. J'essaie n'importe quelle combinaison de d's et de r que vous voulez mentionner, mais ça reste là. Mon écran est là, il ne fera rien, et surtout ne reprendra pas.

Quelqu'un a-t-il des conseils, des astuces ou des idées sur la façon de reprendre ma session d'écran?

Réponses:


16

Je l'ai vu lorsque je supprime une connexion à un écran actif, puis que je me reconnecte. Le bogue n ° 27462 («Reconnecte les blocages lorsque la session d'origine est perdue») décrit le problème tel que je le vois. Ce qui semble se produire, c'est que l'écran essaie d'avertir le tty qui le détient qu'il est sur le point de partir, mais comme le tty est bloqué en raison d'une connexion interrompue, il doit attendre que le délai d'attente se produise (qui est supérieur à cinq minutes dans certains cas).

Pour le réparer, je fais ceci:

  • déterminer quel tty tient à la session écran ps -ef | grep screen | grep pty
  • trouver le bash de connexion associé à ce tty ps -ef | grep bash | grep $PTY
  • tuez ce bash kill -KILL $PID

Cela fait que l'écran termine correctement sa déconnexion et vous permet de vous reconnecter normalement.

Voir ici pour un exemple de script automatisant quelque peu cela.


ps -ef | écran grep | grep tty n'imprime jamais rien parce que ps -ef | grep screen ne renvoie jamais rien avec la chaîne tty.
Dave Aaron Smith

En fait, l'exemple de script semble faire l'affaire. Merci!
Dave Aaron Smith

1
Ouais, je voulais dire «pty», pas «tty».
David Mackintosh

2

J'ai eu un problème similaire avec mes sessions d'écran. Je les nomme et les configure en tant que sessions multi-utilisateurs. Ce que j'ai trouvé, c'est qu'il faisait la liste de mes sessions mais me disait que je n'avais aucune connexion à laquelle me connecter. J'ai ensuite essayé:

screen -x <session_name>

Cela a fonctionné comme un champion!


1

Je ne peux pas dire que j'ai jamais eu de problème avec l'écran qui ne revient pas, quel que soit le type de connexion sur lequel je suis Ma méthode habituelle:

ssh myname@foo
screen -S sessionName
(do my work... get disconnected...)

ssh myname@foo
screen -d (just to make sure anything wasn't left attached)
screen -r sessionName

1
Par exemple, screen -list renvoie 32322.mySession (attaché). Ensuite, je sélectionne -d mySession. Ensuite, screen -list renvoie toujours 32322.mySession (ci-joint), et screen -r mySession renvoie Aucun écran ne doit être repris pour correspondre à daveSession.
Dave Aaron Smith

avez-vous essayé juste "screen -d"?
Jason Antman

0

Est-il possible que ce bug vous affecte?

http://savannah.gnu.org/bugs/?27462

Pouvez-vous essayer de faire la solution de contournement qu'ils recommandent et voir si cela fonctionne?


La solution de contournement n'avait pas beaucoup de sens pour moi. Ma sortie de l'écran ps -ef | grep ne ressemble pas du tout à l'exemple.
Dave Aaron Smith

0

Soulrce: https://kb.iu.edu/data/ahrm.html

To see your existing screen sessions, enter:
  screen -list
This will display a list of your current screen sessions. For instance, if you had one attached screen, you would see:

         1636.pts-21.hostname      (Attached)

To detach an attached screen, enter:
  screen -D
If you have more than one attached screen, you can specify a particular screen to detach. For example, to detach the screen in the above example, you would enter:
  screen -D 1636.pts-21.hostname

0

Si vous êtes intelligent comme moi, vous tentiez de reprendre une session d'écran commencée comme rootavec le compte utilisateur normal. ls /var/run/screenJ'ai découvert cela en me montrant un répertoire pourroot


0

J'ai parfois le même problème (screen -r -d ne reprend pas, ne répond pas). Pour corriger, recherchez le terminal (tty / pty) associé à la session écran:

screen -list
There is a screen on:
    28176.pts-51.localhost        (Attached)
1 Socket in /tmp/uscreens/S-xxxx.

Recherchez le terminal répertorié (dans cet exemple pts-51):

ps axuw | grep 'pts/51'   # will vary depending upon how pty's are named
you     12293  0.0  0.2  2148 1128 pts/51   Ss   10:34   0:00 -bash

Tuez les processus sur ce terminal (généralement votre shell):

kill 12293

exécutez à nouveau ps pour vous assurer qu'il a disparu. Si non :

kill -9 12293

Sur mon serveur (gnu / linux), je devrai parfois tuer -9 plusieurs fois jusqu'à ce qu'il meure.

Une fois tous les processus sur ce terminal terminés, l'écran devrait reprendre correctement:

screen -r -d

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.