Bug 58120 - xoff'd screen session causes bad behavior
xoff'd screen session causes bad behavior
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Copeland
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-09 00:56 EST by James Manning
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-09 00:56:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Manning 2002-01-09 00:56:20 EST
Description of Problem:
if you xoff (^A^S) a screen session, you get bad screen -d behavior:

1) remote screen -d doesn't act right.  Specifically, an initial remote
   screen -d will fail to actually detach the session.  screen -ls runs
   before and after show it still attached.  But, strace shows that the
   syscalls do at least *seem* valid, since the write works:

open("/tmp/uscreens/S-jmm/1949.tty1.bp6", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 500
getegid32()                             = 500
fcntl64(0x4, 0x4, 0, 0x8096018)         = 0
geteuid32()                             = 500
getegid32()                             = 500
getdents64(0x3, 0x8095010, 0x1000, 0)   = 0
close(3)                                = 0
geteuid32()                             = 500
getegid32()                             = 500
setuid32(0x1f4)                         = 0
setgid32(0x1f4)                         = 0
stat64("/tmp/uscreens/S-jmm/1949.tty1.bp6", {st_mode=S_IFIFO|0700, 
st_size=0, ...}) = 0
getpid()                                = 32758
write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336) = 
12336
close(4)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40018000
write(1, "[1949.tty1.bp6 detached.]\n", 26[1949.tty1.bp6 detached.]
) = 26

   So we have one screen -d attempted, and silently failed.
   Worse, a second screen -d run will *HANG* (on the write syscall to be
   specific).  Notice that the
   open() syscall in the above strace is very specific on O_WRONLY
   and O_NONBLOCK so this hang is kind of confusing me and making me
   worry about deeper issues at hand.

the strace ending from that second, hanging screen -d

open("/tmp/uscreens/S-jmm/1949.tty1.bp6", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 500
getegid32()                             = 500
fcntl64(0x4, 0x4, 0, 0x8096018)         = 0
geteuid32()                             = 500
getegid32()                             = 500
getdents64(0x3, 0x8095010, 0x1000, 0)   = 0
close(3)                                = 0
geteuid32()                             = 500
getegid32()                             = 500
setuid32(0x1f4)                         = 0
setgid32(0x1f4)                         = 0
stat64("/tmp/uscreens/S-jmm/1949.tty1.bp6", {st_mode=S_IFIFO|0700, 
st_size=0, ...}) = 0
getpid()                                = 310
write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336

The screen -d hangs until either interrupted (^C) *or* the screen session
is xon'd again (^A^Q), at which point the above strace finishes:

write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336) = 
12336
close(4)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40018000
write(1, "[1949.tty1.bp6 detached.]\n", 26[1949.tty1.bp6 detached.]
) = 26
write(1, "\r\n", 2
)                     = 2
munmap(0x40018000, 4096)                = 0
_exit(0)                                = ?

Version-Release number of selected component (if applicable):
screen-3.9.9-3

How Reproducible:
100%
Comment 1 Phil Copeland 2002-05-09 15:43:38 EDT
Reporting upstream
This problem exists in 3.9.11 as well

Phil
=--=

Note You need to log in before you can comment on or make changes to this bug.