Bug 58120
| Summary: | xoff'd screen session causes bad behavior | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | James Manning <jmm> |
| Component: | screen | Assignee: | Phil Copeland <copeland> |
| Status: | CLOSED WONTFIX | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-01-09 05:56:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Reporting upstream This problem exists in 3.9.11 as well Phil =--= |
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%