Не удается повторно подключиться к сеансу экрана после разрыва соединения SSH

Ранее я подключался к длительному сеансу экрана с screen -dr control. Однако иногда эта команда не присоединяется к экрану и вместо этого зависает навсегда (через 10 с лишним минут после этого я прервалась). Это происходит только тогда, когда соединение SSH неожиданно обрывается, а не тогда, когда экран должным образом отключен Ctrl-A d. Другие переключатели, такие как screen -xили screen -D -RRтакже не работают.

Этот пост предлагает убить PTY, который содержит сеанс экрана, что заставит экран завершить его отключение. Однако он просто убивает оболочку, из которой screen -dr controlбыл вызван.

Например:

$ 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

Связанный пост предлагает убить bashпроцесс с PID 7109. Это также убьет screen -dr controlпроцесс с PID 7387. После этого я все еще не могу подключиться к экрану.

Процесс, SCREEN -S controlзапустивший сеанс экрана, имеет initсвоего родителя, которого я, очевидно, не могу убить.

Есть ли способ присоединиться к зависшей сессии экрана?

Обновление: это происходит в CentOS 6.4 с использованием ядра 2.6.32-358.6.1.el6.x86_64. Все оболочки - bash версии 4.1.2 (1) -релиз.

ssh gnu-screen

— Виктор Розенфельд
источник

Что screen -lsговорит в этих «висящих» случаях? screen -d -r <session>означает «отсоединить и восстановить», поэтому не имеет значения, не отрывая его от себя. (И делать это часто, это не ...)

— mveroone

Попробуйте запустить на экране процессы lsof, посмотрите, не застряло ли что-нибудь. Screen использует Unix-сокет для связи между процессами, вероятно, что-то сохранило его открытым. Также убедитесь, что сокет не был удален или его владелец не изменился или что-то еще. В общем, вы также должны указать, какую ОС и версию вы используете, хотя я не имею в виду ничего особенного, что в этот раз зависело бы от ОС.

— Дэн Притц

Вы ssh'ing через другой прыжок, например, используя netcat в качестве прокси-команды? В этом случае у меня возникла проблема, когда соединение ssh с первым блоком прерывается, но команда netcat proxy сохраняет «второе» соединение ssh открытым. однако -d должен работать.

— Дженс Тиммерман

Дженс, твой совет сработал. Я действительно сделал прокси через netcat и убил его на промежуточном хосте, что позволило мне снова подключиться к экрану.

— Виктор Розенфельд

Почему вы хотите убить родительский процесс команды зависшего экрана? Вы хотите убить саму команду прикрепления экрана. # 7387 в вашем случае.

— Матиас Урликс

Я думаю тебе стоит попробовать

screen -DR

и в следующий раз - гневный (в верхнем регистре) вызов должен заставить его отключить другой сеанс, поддерживаемый промежуточным прыжком netcat.

— пацифист
источник

Я пробовал это, это не работает. Убийство прокси netcat делает свое дело.

— Виктор Розенфельд

Странный. Должно. Что происходит вместо этого?

— Матиас Урлич

Все последующие вызовы экрана (-dr, -x, -DR) навсегда останутся. Как только я убил прокси netcat, эти вызовы снова работают.

— Виктор Розенфельд

Как предположил Дженс Тиммерман, основной причиной такого странного поведения было то, что я подключался к удаленному серверу с помощью SSH ProxyCommand и ncat. После убийства ncatна промежуточной машине я могу снова подключиться к экранной сессии.

— Виктор Розенфельд
источник

-2

Если это частая проблема, вы также можете использовать mosh в качестве замены ssh:

http://mosh.mit.edu

— Фред Конклин
источник