Impossible de se reconnecter à une session d'écran après la coupure de la connexion SSH

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 -xou 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 bashprocessus avec le PID 7109. Cela va également tuer le screen -dr controlprocessus avec le PID 7387. Par la suite, je ne peux toujours pas me connecter à l'écran.

Le processus SCREEN -S controlqui a commencé la session d'écran a initpour 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).

ssh gnu-screen

— Viktor Rosenfeld
source

Que screen -lsdit 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 ...)

— mveroone

Essayez d'exécuter lsof sur les processus d'écran, voyez s'il y a quelque chose de «bloqué». L'écran utilise une socket Unix pour communiquer entre les processus, probablement quelque chose l'a gardé ouvert. Assurez-vous également que le socket n'a pas été supprimé ou que sa propriété a changé ou quelque chose. En général, vous devez également inclure le système d'exploitation et la version que vous utilisez, même si je n'ai rien de particulier à l'esprit qui serait dépendant du système d'exploitation cette fois-ci.

— Dan Pritts

Utilisez-vous un autre saut, par exemple en utilisant netcat comme commande proxy? Dans ce cas, j'ai eu le problème où la connexion ssh à la première boîte tombe, mais la commande proxy netcat garde une «seconde» connexion ssh ouverte. le -d devrait cependant fonctionner.

— Jens Timmerman du

Jens, vos conseils ont fait l'affaire. J'ai effectivement fait un proxy via netcat et le tuer sur l'hôte intermédiaire m'a permis de me rattacher à l'écran.

— Viktor Rosenfeld

Pourquoi voudriez-vous tuer le processus parent de la commande d'écran bloqué? Vous voulez tuer la commande d'écran de connexion elle-même. # 7387 dans votre cas.

— Matthias Urlichs le

Je pense que tu devrais essayer

screen -DR

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.

— pacifiste
source

J'ai essayé ça, ça ne marche pas. Tuer le proxy netcat fait l'affaire.

— Viktor Rosenfeld

Étrange. Cela devrait. Que se passe-t-il à la place?

— Matthias Urlichs

Toutes les autres invocations d'écran (-dr, -x, -DR) se bloquent pour toujours. Une fois que j'ai tué le proxy netcat, ces invocations fonctionnent à nouveau.

— Viktor Rosenfeld du

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é le ncatsur la machine intermédiaire, je suis en mesure de me reconnecter à la session d'écran.

— Viktor Rosenfeld
source

-2

Si c'est un problème fréquent, vous pouvez également envisager d'utiliser mosh en remplacement de ssh:

http://mosh.mit.edu

— Fred Concklin
source