Comment 4 for bug 113586

Yes, I am aware of the symlink workaround, and no, it does not solve the problem, which is pretty surprising. Details below.

It also appears that my evaluation and workaround above was also incorrect, or at least incomplete.

And it looks like I never mentioned the all details of the setup, sorry. The user homedir is a symlink into AFS space. Authentication is kerberos 5, and pam_openafs_session is used to get afs tokens.

This issue is still unsolved for me: my machine is still preventing me from logging in if there is already an ongoing login session which has lost AFS tokens. This is the real emphasis of this bug report: a login session which has lost AFS tokens not only is borked itself, of course, but somehow also manages to bork all other attempts to log in as that user, whether from a different VT, via ssh, or by su.

I've minimized the annoyance by setting my kerberos tickets for maximum renewable lifetime. So now I only need to deal with this mess once every week or so.

Other than rebooting, I've found two ways out of the wedge. One is to log in as root (which does work) and then kill all processes of the offending user. After they've died, new logins as that user work again. The other way out is to temporarily rename the user's homedir. Then logins as that user fail to find the homedir at all, but at least they don't hang. This doesn't really help much...

I have tried many times to strace attempts to su to the user from a root login to determine where the hang is occurring. In all cases I have observed so far it appears that it is, in fact, hanging while trying to read some dotfile in the homedir, which is of course unreadable. However I have now made all these dotfiles symlinks to files on a local filesystem, but the login attempts *still* hang trying to read the symlinks. I find this fairly bizarre and even inconsistently repeatable -- I am pretty sure that the hangs don't always occur on the same dotfile.