Bug 65344
Summary: | screen crashes when attempting to reconnect to a session | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Joseph Kotran <jkotran> |
Component: | screen | Assignee: | Lon Hohberger <lhh> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | mikem |
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-11-14 16:53:03 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: |
Description
Joseph Kotran
2002-05-22 14:48:50 UTC
Follow-up: I disabled the password line in my .screenrc. I can detach/reconnect properly. However, this is not a good work around. *scratch* Well the only thing I can think of is that you have a different locale than me I use the en_US locale which might be affecting screens behaviour The other thing is what type of crpt that passwd is in. ie BSD crypt or MD5 passswd format (ala default shadow passwd format) I tried to crash it in the manner you describe and it didn't die I'll ask a coworker here to try it in case I missed something. Phil =--= Ok this does blow up on another box (oddly not mine,,, hummm) I'll get around to this when I can though the most likely suspect at this time is PAM as something goes horribly wrong during the reattach because a signal is generated bu theres no handler for it an we 'hang' Phil =--= Reproduced in test lab Request status update. I am unable to use screen to administrate my servers. Please advise. Hello, I built screen 3.9.11 from source to see if the password reconnect trouble was caused by the method in which the Red Hat 7.3 rpm was packaged. I experienced the same trouble as documented in my original bug report. I downgraded to screen 3.9.10 and the problem is not present. I am able to successfully disconnect and reconnect to screen session that is password protected. Please make screen revision 3.9.10 the one that you support for your next release. I also encourage you to issue an errata regarding this bug. Thank you, Joe Kotran Ok, lets try on an alpha (RH 7.2 base) ======================================================= [test@alpha test]$ rpm -q screen screen-3.9.11-8 [test@alpha test]$ screen <ctrl-a d> [detached] [test@alpha test]$ cat .screenrc # Various incants of the password 'root' # # MD5sum #password $apr1$/Zpcu/..$PCErz4Hb.lq8aOs/d5TBE1 # CRYPT password 4g0foaVFOG24k # SHA #password {SHA}CQa6ORNnoZC4jqe1W91DCi7MdY4= [test@alpha test]$ screen -dR Screen password: **** (root) screen reattaches No problems ======================================================= Lets try 7.3 (screen-3.9.11-3) [test@bryce2 test]$ screen <ctrl-a d> [detached] [test@bryce2 test]$ screen -dR Screen password: **** (root) No Problems ======================================================= Ok that was -3, lets upgrade it to -8 [test@bryce2 test]$ rpm -q screen screen-3.9.11-8 [test@bryce2 test]$ screen <ctrl-a d> [detached] [test@bryce2 test]$ screen -dR Screen password: **** (root) No problems Sorry, I cannot reproduce this bug I *can* reproduce this bug. Here are some details: First of all, even with no .screenrc, the pow_detach keybinding does not work. OTOH, screen -D does pow_detach a remote session and typing pow_detach at the screen command line (^A:) works too. The pow_detach keybinding (^AD) prints a capital D at the bottom of the screen and waits. Upon a second keystroke, the message line reads "pow_detach aborted". Even with the simple two-line .screenrc: password 4g0foaVFOG24k startup_message off I am able to reproduce this bug. This was on an x86. Various permutations of screen -R cause the dungeon to collapse. # rpm -q screen screen-3.9.11-3 Ok,.. after **MUCH** headscratching and dragging hapless engineers away from bed, it ould appear this is a UTF8 encoding problem. Since the utf8 encoding ability is mostly a limbo thing (there was a minor attempt at it in 7.3, I'm disabling UTF8 support * define UTF8 if you want support for UTF-8 encoding. * Needs FONT and ENCODINGS to work. Basically things go horribly wrong when it's trying to repaint the screen canvas and draw out UTF8 chars (bails out in display.c - function dis_readev_fn() about line 3373 where one of the structures gets nuked and a null pointer is passed in -> SEGV and then the Dungeon collapses etc,... This is a new feature that 3.9.11 has over 3.9.10 so it's not terribly unreasonable to kick it out as being unstable for the time being. Hence why one person did not see this behaviour in an older 3.9.10. If you look you'll probably find that your default local is not en_US but en_US.UTF-8 I never saw the problem because my default locale is en_US I've rebuilt screen to drop support for utf8 encodings /* #undef ENCODINGS */ /* #undef UTF8 */ Try 3.9.11-10 from rawhide. It would appear to work (unless it built wrong in the build system) Phil =--= Any news on 3.9.11-10 testing? lhh- 3.9.11-10 in 8.0 doesn't have the problem. CLOSING->CURRENTRELEASE |