Екран GNU зависає при спробі повторного приєднання

У мене є кілька тривалих сеансів екрану GNU. Я піднімаю до вікна, на якому вони працюють, і запускаю їх, screen -d -r fooщоб від'єднати їх, якщо вони підключені деінде, і прикріплюю їх у моєму поточному вікні.

99% часу це працює добре, але при нагоді я отримую це:

$ screen -d -r foo
[2430.foo detached.]

... і нічого не відбувається; Я взагалі не можу повернутися до оболонки. Спроба в іншому вікні робить те саме, єдине, що я можу зробити, це знищити цей сеанс на екрані (втрачаючи всі програми, що працювали в ньому) і відтворити його

Чому це відбувається? Як я можу цього уникнути або успішно підключитися, коли це відбувається?

Редагувати : Мій .screenrc:

startup_message off
defwritelock off
bind q quit
caption always '%{gk}   (%n) %t                   %{y}%d %M %Y :: %c:%s                   %{b}%W%{d}'
screen -t ZSH
autodetach on
shelltitle ZSH
defutf8 on

Редагувати : кінець straceжурналу при спробі вкласти:

readlink("/proc/self/fd/0", "/dev/pts/14", 4095) = 11
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
stat64("/dev/pts/14", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 14), ...}) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/dev/pts/14", O_RDWR|O_NONBLOCK)  = 3
geteuid32()                             = 1000
getegid32()                             = 1000
close(3)                                = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
umask(0)                                = 022
lstat64("/var/run/screen", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
access("/var/run/screen/S-mrozekma", F_OK) = 0
stat64("/var/run/screen/S-mrozekma", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
umask(022)                              = 0
uname({sys="Linux", node="etudes-2", ...}) = 0
rt_sigaction(SIGHUP, {0x806e520, [], 0}, {SIG_DFL, [], 0}, 8) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/var/run/screen/S-mrozekma", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 6 entries */, 32768)     = 124
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
geteuid32()                             = 1000
getegid32()                             = 1000
open("/var/run/screen/S-mrozekma/2386.chat", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 1000
getegid32()                             = 1000
fcntl64(4, F_SETFL, O_RDONLY)           = 0
geteuid32()                             = 1000
getegid32()                             = 1000
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
geteuid32()                             = 1000
getegid32()                             = 1000
setuid32(1000)                          = 0
setgid32(1000)                          = 0
stat64("/var/run/screen/S-mrozekma/2386.chat", {st_mode=S_IFIFO|0700, st_size=0, ...}) = 0
getpid()                                = 30081
write(4, "\0gsm\4\0\0\0/dev/pts/14\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336

Не впевнений, чи був у мене такий самий випуск, як і у вас, але іноді я маю подібну поведінку екрана кожного разу, коли мережу випадково відключали.

Через деякий час (приблизно 10–15 хвилин) екран знову з’явиться для відновлення. Після кількох інвестицій я знайшов невелику записку на сторінці чоловіка:

   nonblock [on|off|numsecs]

   Tell  screen  how to deal with user interfaces (displays) that cease to
   accept output. This can happen if a user presses ^S or a TCP/modem con‐
   nection gets cut but no hangup is received. If nonblock is off (this is
   the default) screen waits until the display restarts to accept the out‐
   put.  If  nonblock is on, screen waits until the timeout is reached (on
   is treated as 1s). If the display  still  doesn't  receive  characters,
   screen will consider it "blocked" and stop sending characters to it. If
   at some time it restarts to accept characters, screen will unblock  the
   display and redisplay the updated window contents.

Можливо, це допоможе комусь, тому що це єдина сторінка про замерзання екрана після того, як мені відмовила Google.

Можливо, ваш сеанс екрана висів у очікуванні псевдотерміналу оболонки, з яким ви востаннє приєднані до екрана. Іноді втрачене з’єднання залишає оболонку навколо та екрана таймаутом, щоб відключитися від нього.

Якщо ви запустите ls -l /proc/<screen_pid>/fd/<descriptor_of_hung_write>, ви повинні побачити, що це очки попереднього сеансу оболонки.

Після того, як ви вб'єте сеанс bash / shell, з яким ви долучились, ви зможете повторно приєднатись.

# ps auwxf|grep -B2 screen
root     23214  0.0  0.0 109304  4016 ?        Ssl  19:13   0:00  \_ sshd: root@pts/6 
root     23566  0.0  0.0 117400  2272 pts/6    Ss   19:13   0:00      \_ -bash
root     10445  0.0  0.0 125156  1156 pts/6    S+   19:23   0:00          \_ screen -ADR MYSCREEN

Я в цьому випадку, процес 2326 убивства випустить сеанс екрану, і ви можете повторно вкласти.

Чи було оновлено екран після запуску сеансів на екрані?

Я не можу згадати точні подробиці, але я пам’ятаю, що близько місяця-трьох тому apt-get dist-upgrade(на debian sid) оновлений екран моєї системи, і пошта попередила мене про несумісне оновлення. Зберігалася копія старого екрана (десь під / tmp IIRC), щоб дозволити повторне приєднання до старих сеансів, але рекомендується вбити та перезапустити їх.

Симптоми, про які ви повідомляєте, звучать аналогічно тому, що я бачив, коли я випадково намагався знову підключитися до старого екранного сеансу з новим / usr / bin / screen.

Можливо, це було, з dpkg.log ще в червні:

2012-06-14 08:11:51 upgrade screen:amd64 4.0.3-14 4.1.0~20120320gitdb59704-2