Екран GNU - неможливо повторно приєднатись до екрана після втрати з'єднання

Я використовував irssi на екрані, але втратив зв’язок. Після того як я повернувся на сервер, я більше не можу приєднатися до цього екрана. screen -ls показує, що екран вже вкладений.

Я спробував screen -D, щоб змусити його від'єднати, і він сказав від'єднати, але екран -ls все ще говорить, що він додається. Я спробував екран -x, і він просто висить там.

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

Що я можу зробити зараз?

Якщо ви намагаєтесь підключити екран "Вкладений", запустіть screen -xr irssi. Верхній регістр '-X' надсилає команду на одне із сеансів на екрані, опція '-x' у малому регістрі дозволяє знову підключитися до доданого сеансу. Але вам все одно потрібно вказати назву сесії, оскільки їх існує більше.

Я прояснив цю поведінку в минулому, вбивши оболонку, яка розпочала сеанс екрана. В основному, вбивство всіх екземплярів bash для мого користувача, які не належали екрану.

Ви дали йому ім'я, яке не використовується за замовчуванням. Спробуйте це:screen -RD irssi

Ви можете спробувати:

#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

screenвідомий тим, що не підтримує зворотну сумісність між версіями. Якщо версія screenсервера була оновлена ​​на сервері, можливо, ви більше не зможете повторно приєднатись до попередніх сеансів на екрані.

У такому випадку ви можете або використовувати старий бінарний екран SCREEN для повторного входження (за умови, що ваш менеджер дистрибутивів збереже його десь), або вбити сеанс взагалі.

Я мав певний успіх, надіславши процес 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

Це сталося зі мною, коли я використовував vi, де сеанс замерз, і я відключився. При спробі повторного приєднання до екрана за допомогою екрана -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-процесу повернуло мій екран. У минулому я зіткнувся з цією проблемою із екраном, і я не раз попробовав те, що більшість людей рекомендували в цій темі. Пошук цього проблемного дитячого процесу - це єдине, що працювало на мене і постійно працювало над цим.

screen -r 4033

screen -x 7728

killall -9 sshd

Це працювало для мене. У мене було 3 різних екрани, і я втратив 3 різних ssh-з'єднання. Після повторного підключення екрани все ще були приєднані, я видав команду вище ... звичайно, я втратив своє поточне з'єднання, але це було свіже. При наступному підключенні кожен екран був знятий.

Зауважте, якщо ви суперпользователь, то вам слід скористатися --userопцією, щоб вбити лише своїх демонів ssh.