再接続しようとしてGNU画面がフリーズする

長時間実行されるGNUスクリーンセッションがいくつかあります。実行中のボックスにsshし、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分）画面が再び接続可能になります。いくつかの調査の後、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>と、前のシェルセッションのポイントであることがわかります。

アタッチしていた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を強制終了すると、画面セッションが解放され、再接続できます。

スクリーンセッションが開始されてからスクリーンがアップグレードされましたか？

正確な詳細を思い出すことはできませんが、1、3か月前、apt-get dist-upgradeに、システム上で（debian sidに）アップグレードされた画面とpostinstが互換性のないアップグレードについて警告したます。古いセッションの再接続を可能にするために、古い画面のコピー（/ tmp IIRCの下）が保持されていましたが、それらを強制終了して再起動することをお勧めしました。

新しい/ usr / bin / screenで古いスクリーンセッションに誤って再接続しようとしたときに見たものに似た音が聞こえます。

6月のdpkg.logからのこれはおそらくこれでした：

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