The virtual screen manager, 'screen', has a lock mode. 1) Lock mode was invoked with Control-x (not Control-a x); this makes nano or Emacs rather interesting... 2) Lock mode does not unlock. I don't think it understands PAM. I emerged xtrlock and it works ok...
Well, lock mode is actually invoked with C-a C-x; it's just that I inadvertently (inside nano, with Emacs key bindings) typed a C-a to move to the beginning of a line, which had no effect since screen grabs that, and then I did some other stuff, more keys, then I wanted to get out of nano so I typed C-x. This locks screen's virtual session. And it never unlocks. No matter what.
Not an error in screen as such, maybe a misconfiguration. You can control which terminal locking program is used through the environment variable LOCKPRG. Without a suitable lock program it appears just to demand the users passwd.
As Bryan said - not so much of a bug, but more a missconfiguration.
It demands the user's password, and you give it the password, and it does NOT UNLOCK. This is not a bug? :-) I have to kill the screen process to get my console back, thereby losing all the jobs managed by screen. Bad! If I am indeed the only person running into this, I would appreciate some pointers on how to set up screen so that it works with Gentoo. The ebuild as-is, the default configuration, seems dangerous to me and I think it should be fixed.
This is a strange bug. At first I wasn't able to reproduce this bug, but I've finally managed to reproduce it. After looking into it a great deal more, it only seems to fail on 2.6 kernels. On my 2.4 boxes it works as expected. Basically what I'm seeing when tracing screen is Permission denied on /proc/self/fd/0. This only happens on 2.6 kernels. I try pushing it upstream, see if the screen maintainers might be aware of this issue.
