Экран GNU зависает, пытаясь снова подключиться

У меня несколько длительных сеансов экрана GNU. Я ssh в окно, в котором они работают, и запускает screen -d -r foo чтобы отсоединить их, если они подключены где-нибудь еще, и затем присоединить их в моем текущем окне.

99% времени это прекрасно работает, но иногда я получаю это:

  • константа "введите кодовую фразу для открытого ключа" ssh
  • Время ожидания подключения SSH
  • Прочитайте первую строку вывода команды. Команда соединяет меня с удаленным терминалом
  • (bash) Script A, ждать сценария B, но не его дочерний процесс
  • Экранная сессия работает от имени root? (это не должно быть) node.js
  • Мой сервер постоянно атакуется
  •  $ screen -d -r foo [2430.foo detached.] 

    … и ничего не происходит; Я вообще не могу вернуться в оболочку. Попытка в другом окне делает то же самое, единственное, что я могу сделать, это уничтожить сеанс экрана (потеряв все запущенные в нем программы) и воссоздать его

    Почему это происходит? Как я могу избежать этого или повторно подключиться, когда это произойдет?


    Изменить : My .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 

  • Как узнать, успешно ли создан мой туннель ssh?
  • SSH-соединение через SSH-туннель продолжает закрываться
  • Передача ssh-agent для Vagrant VM
  • Не удалось выполнить ssh в Ubuntu 12.04 LTS [не удалось разрешить имя хоста (имя хоста): имя или услуга неизвестны
  • изменить оболочку в Solaris / SunOS для вашего пользователя только без доступа к / etc / passwd
  • Уведомления SSH для внешних IP-адресов
  • 3 Solutions collect form web for “Экран GNU зависает, пытаясь снова подключиться”

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

    Через некоторое время (около 10-15 минут) экран снова доступен для повторного подключения. После некоторых попыток, я нашел небольшую заметку на странице man:

      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> , вы увидите, что это pts для предыдущего сеанса оболочки.

    Когда вы убьете сеанс 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 

    В этом случае процесс 23214 убийства освободит сеанс экрана, и вы можете снова подключиться.

    Был ли обновлен экран с тех пор, как начались эти сеансы?

    Я не могу вспомнить точные детали, но я помню, что примерно месяц или три назад обновленный экран apt-get dist-upgrade (to debian sid) обновил мою систему, и postinst предупредил меня о несовместимом обновлении. Копия старого экрана была сохранена (где-то под / 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

    Linux и Unix - лучшая ОС в мире.