Description of Problem: screen crashes when attempted to reconnect to a session Version-Release number of selected component (if applicable):screen-3.9.11-3 How Reproducible: everytime Steps to Reproduce: 1. Set a screen password via ~/.screenrc 2. Execute `screen` 3. Press Control+A D to detach 4. Execute `screen -D -R` to attempt to reconnect 5. Enter your password Actual Results: % screen Screen password: Suddenly the Dungeon collapses!! - You die... % ******* *******: Command not found. (The ***'s are the last seven characters of my eight character password. It is echoed in plain text!) Expected Results: Not this. :-) Additional Information: My .screenrc: activity 'Activity in window %n' autodetach on bell_msg 'Bell in window %n' bind \\ quit escape ^Oo msgwait 3600 password ************* (crypted password; has worked since Red Hat 6.2) screen -t localhost 1 screen -t localhost 2 scrollback 1500 silencewait 30 startup_message off vbell_msg 'End'
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