23

Я использовал irssi на экране, но потерял связь. После того, как я вернул ssh на сервер, я больше не могу подключаться к этому экрану. screen -ls показывает, что экран уже подключен.

Я попробовал screen -D, чтобы заставить его отсоединить, и он сказал отсоединиться, но screen -ls все еще говорит, что он подключен. Я попробовал screen -x, и он просто завис там.

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

Что я могу сделать сейчас?

9 ответов9

13

Если вы пытаетесь подключить экран «Attached», запустите screen -xr irssi . «-X» в верхнем регистре отправляет команду на один из сеансов экрана, параметр «-x» в нижнем регистре позволяет вам повторно подключиться к присоединенному сеансу. Но вам все равно нужно дать имя сеанса, так как их больше одного.

9

Я прояснил это поведение в прошлом, убив оболочку, которая начала сеанс экрана. По сути, уничтожение всех экземпляров bash для моего пользователя, которые не принадлежали screen.

4

Вы дали ему имя не по умолчанию. Попробуйте это: screen -RD irssi

4

ты можешь попробовать:

#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

всегда полезно использовать полное имя pid.tty

3

screen известен как не совместимый между версиями. Если версия screen была обновлена на сервере, возможно, вы больше не сможете подключиться к более старым сеансам экрана.

В этом случае вы можете либо использовать старый двоичный файл SCREEN для повторного присоединения (если ваш менеджер пакетов распространения сохранил его где-то), либо полностью прекратить сеанс.

2

У меня был некоторый успех, послав процесс GNU/screen SIGCHLD (который он обычно получает, когда окно закрыто), это заставляет его коснуться (и, возможно, воссоздать) файл сокета.

Также обратите внимание, что существует два способа вызова исполняемого файла screen которые отличаются только в том случае, если: SCREEN - это компонент на стороне сервера, к которому вы пытаетесь подключиться, в то время как screen - это сторона на стороне клиента, которая перетасовывает данные между вашим терминалом и стороной сервера. , Так что вы можете попробовать убить строчную версию ...

Например, в следующем вы можете увидеть, что мой screen и процессы SCREEN не считаются родительскими и дочерними, что указывает на то, что я подключен к существующему сеансу.

# 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

Свежие сессии выглядят так:

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

Это случилось со мной, когда я использовал vi, когда сессия зависла, и я отключился. При попытке подключиться к экрану с помощью screen -Arx процесс просто зависнет.

Может быть запущен похожий дочерний процесс, вызывающий зависание экрана. Если вы помните один конкретный акцент на этом, в противном случае, чтобы получить список дочерних процессов, запущенных под вашим экраном, выполните:

ps ux -H

Который покажет вложенные дочерние процессы:

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

После завершения процесса vi, который вызвал проблему, я смог снова подключить экран без каких-либо проблем. Убийство всех предыдущих процессов, которые были подключены к экрану, вероятно, также является хорошей идеей. Просто используйте:

kill -9 <pid>

Я не знаю, что делает внутренне экран, почему vi вызвал зависание экрана, или почему остановка процесса vi вернула мой экран. В прошлом я сталкивался с этой проблемой с экраном и безуспешно пытался рекомендовать то, что большинство людей рекомендовали в этой теме. Нахождение этой проблемы дочерний процесс - единственное, что сработало для меня и работало последовательно в этом.

0
screen -r 4033

screen -x 7728
0
killall -9 sshd

Это сработало для меня. У меня было 3 разных экрана, и я потерял 3 разных соединения ssh. После переподключения экраны все еще были подключены, я дал команду выше ... конечно, я потерял свое текущее соединение, но оно было свежим. При следующем переподключении каждый экран был отключен.

Обратите внимание: если вы являетесь суперпользователем, то вам следует использовать опцию --user чтобы убить только ваши ssh-демоны.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .