J'ai précédemment attaché à une session d'écran de longue durée avec screen -dr control
. Cependant, parfois, cette commande ne se rattache pas à l'écran et se bloque à la place pour toujours (10+ minutes après lesquelles j'ai avorté). Cela se produit uniquement lorsque la connexion SSH est interrompue de manière inattendue et non lorsque l'écran est correctement détaché avec Ctrl-A d
. D'autres commutateurs, tels que screen -x
ou screen -D -RR
également ne fonctionnent pas.
Ce message suggère de tuer le PTY qui détient la session d'écran, ce qui entraînera la fin de la déconnexion de l'écran. Cependant, il tue simplement le shell à partir duquel il a screen -dr control
été appelé.
Par exemple:
$ ps -ef | grep control | grep -v grep
nomad 7387 7109 0 13:05 pts/50 00:00:00 screen -dr control
nomad 15299 1 0 Nov27 ? 00:13:47 SCREEN -S control
$ ps -ef | grep bash | grep 'pts/50'
nomad 7109 7108 0 12:49 pts/50 00:00:00 -bash
Le message lié suggère de tuer le bash
processus avec le PID 7109. Cela va également tuer le screen -dr control
processus avec le PID 7387. Par la suite, je ne peux toujours pas me connecter à l'écran.
Le processus SCREEN -S control
qui a commencé la session d'écran a init
pour parent que je ne peux évidemment pas tuer.
Existe-t-il un moyen de se reconnecter à la session d'écran suspendu?
Mise à jour: cela se produit sur CentOS 6.4 à l'aide du noyau 2.6.32-358.6.1.el6.x86_64. Les shells sont tous des versions bash 4.1.2 (1).
la source
screen -ls
dit dans ces cas "suspendus"?screen -d -r <session>
signifie "détacher et récupérer", donc ne pas l'avoir détaché de première main ne devrait pas avoir d'importance. (Et pour le faire souvent, ce n'est pas le cas ...)Réponses:
Je pense que tu devrais essayer
la prochaine fois aussi - l'appel fâché (en majuscules) devrait le forcer à déconnecter cette autre session détenue par votre hop netcat intermédiaire.
la source
Comme suggéré par Jens Timmerman, la raison ultime de ce comportement étrange était que je me connectais au serveur distant à l'aide de SSH ProxyCommand et
ncat
. Après avoir tué lencat
sur la machine intermédiaire, je suis en mesure de me reconnecter à la session d'écran.la source
Si c'est un problème fréquent, vous pouvez également envisager d'utiliser mosh en remplacement de ssh:
http://mosh.mit.edu
la source