Package: screen
Version: 4.0.3-0.3+b1
Severity: normal
Got all running screens halted. When trying to reconnect to them, client
just halts. If I strace the mother-screen, I get:
*$> sudo strace -fF -p 6559
Process 6559 attached - interrupt to quit
write(4, "0m\33[32m0.01 0.13 0.36 \33[1m\33[30m]"..., 1196494
$> sudo ls -l /proc/6559/fd/4
lrwx------ 1 root root 64 2007-06-10 10:00 /proc/6559/fd/4 -> /dev/pts/0
and nothing is happening... had to kill it...
In gdb it looks like:
#0 0xb7ef1792 in ?? () from /lib/ld-linux.so.2
#1 0xb7ddd733 in write () from /lib/tls/i686/cmov/libc.so.6
#2 0x08079dd6 in _nc_timed_wait ()
#3 0x0807e657 in _nc_timed_wait ()
#4 0x0804bd69 in ?? ()
#5 0xbf894f88 in ?? ()
#6 0x00001f9c in ?? ()
#7 0x0808cdb2 in _IO_stdin_used ()
#8 0xbf896fa8 in ?? ()
#9 0x080a5342 in ?? ()
#10 0x080a5345 in ?? ()
#11 0xffffffff in ?? ()
#12 0x080a5342 in ?? ()
#13 0xffffffff in ?? ()
#14 0x00000000 in ?? ()
unfortunately I don't have symbols file
from attaching screen side it looks like
30129 open("/var/run/screen/S-yoh/6559.MAIL", O_WRONLY|O_NONBLOCK) = 4
30129 geteuid32() = 47521
30129 getegid32() = 47522
30129 fcntl64(4, F_SETFL, O_RDONLY) = 0
30129 geteuid32() = 47521
30129 getegid32() = 47522
30129 getdents64(3, /* 0 entries */, 4096) = 0
30129 close(3) = 0
30129 geteuid32() = 47521
30129 getegid32() = 47522
30129 setuid32(47521) = 0
30129 setgid32(47522) = 0
30129 stat64("/var/run/screen/S-yoh/6559.MAIL", {st_mode=S_IFIFO|0700,
st_size=0, ...}) = 0
30129 getpid() = 30129
30129 write(4, "\0gsm\4\0\0\0/dev/pts/21\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336)
= ? ERESTARTSYS (To be restarted)
30129 --- SIGINT (Interrupt) @ 0 (0) ---
30129 +++ killed by SIGINT +++
SIGINT is due to my Ctrl-C
In the #366280 there was a comment about seems to me similar case:
" Odds are it will be blocked on a read/write from/to a fd. Typically this
" happens when you have an ssh session that drops and the socket is
" waiting for tcp to timeout.
" --
" Adam Lazur
I guess, it could be the case in my situation, and I don't remember what
is the duration of tcp timeout but I had been waiting for more than 12h now, so
I guess it might be something different. Also I already killed all
trying-to-attch screens, and tried to attach with a new one but nothing happens
as before. Since it does though block on writing to fd (/proc/6559/fd/4 ->
/dev/pts/0) I just wonder if there is a way to unblock this operation.
Also there is an elderly #103771 which says that sessionname is an ugly
hack. Since it is a documented feature I have been using it for a while and
probably it is not related to my case anyways.
P.S. I am not sure if it is related but I also got VNC stuck on another box, in
which I had an xterm with ssh to the box where stuck screens are running, and
which had session attached to that screen. Killing VNC server didn't help to
resolve problem with screen on remote box (not that it should have but
...)
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (900, 'stable'), (600, 'unstable'), (300,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.20-1-vserver-686 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages screen depends on:
ii base-passwd 3.5.11 Debian base system master password
ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libncursesw5 5.5-5 Shared libraries for terminal hand
ii libpam0g 0.79-4 Pluggable Authentication Modules l
ii passwd 1:4.0.18.1-7 change and administer password and
screen recommends no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
