unknown hang breaks all authentication, happens intermittently

[Simon Ruggier]

This has been happening since at least as long ago as 8.04. I would try to unlock my screensaver after a long time away from my computer and find that it hangs within the authentication stage. At times, a console login would work, after a long delay of 1-2 minutes, allowing me to see what was in my session before rebooting. I recently upgraded to Intrepid, and I'm now noticing that the problem is still here.

Just now, it happened while I was actually using the machine, rather than during a long period of absence. I had opened Synaptic 20 minutes before, and I tried to open it again, but nothing came up. I then opened up a terminal, ran sudo -l, and entered my password, opened another terminal, ran su, and entered gibberish, since there is no root password on this system. That was at least 15 minutes ago, and both commands are still hung up in authentication. I eventually tried synaptic again and found that now that the sudo timeout has expired, a gksu dialog popped up, but upon entering my password there, it disappeared and that gksu froze as well.

Perhaps this is a problem with PAM, but I'm not sure what to do to diagnose it. I don't want to be stuck with this problem for another 6 months.

[Simon Ruggier (simon80)]

A week ago, this problem started happening often, requiring me to reboot my system once or twice a day at a minimum, for a few days straight. In response to this, I tried blacklisting the iwlagn module, under the assumption that this is a hardware/driver related problem, and that the most suspect drivers in my experience are the wireless and graphics drivers. Since blacklisting iwlagn, I haven't seen this problem at all, and my current uptime is over 5 days.

[Steve Langasek (vorlon)]

Hi Simon,

Could you please post the contents of /etc/pam.d/common-{auth,account,session} from your system?

I can see no reason that blacklisting a driver would affect PAM working (and this does seem to point to PAM, since it affects multiple different services). Does blacklisting iwlagn change whether you have a network connection?

[Simon Ruggier (simon80)]

No, I use ethernet for my networking. The problem started happening again recently (with iwlagn still blacklisted), and I couldn't stand having to use the sysrq key to reboot every time I wanted to use my computer after a long period of inactivity, so I upgraded to Jaunty in the hope that it would go away (thankfully, I haven't seen it again so far, though I miss Amarok 1, and JuK/Phonon seem to have reliability issues).

One other notable thing was that if I switched into a VT and hit Ctrl+Alt+Del when auth wasn't working, the shutdown process would hang on whatever daemon was first to be stopped (or something similar, I don't remember). On the other hand, if I used Alt+SysRq+e and then hit Ctrl+Alt+Del (whether it's the first or second time hitting it), shutdown would proceed properly. I think at one point I also found that after hitting Alt+SysRq+e, I was able to log in properly, but this isn't a useful workaround, since the system is presumably not in a good state after sending a TERM signal to every process.

I'll attach an archive with the three files you requested (from a backup that was taken before I upgraded), but you'll probably find that they're untouched, because I don't know anything about PAM.

[Steve Langasek (vorlon)]

The pam backup appears to come from Ubuntu 8.10, not from 8.04; and it is pristine. This was important to verify because in Ubuntu 8.10 and above, additional PAM module packages will auto-enable themselves when installed.

So I don't really see any way that this could be a PAM bug. Indeed, a PAM bug would definitely not explain hangs when trying to shut down daemons on reboot. I'm removing the package assignment on this report.

If you manage to reproduce the bug again with jaunty, please check the output of the 'dmesg' command; I suspect a kernel problem more than anything.

[Simon Ruggier (simon80)]

I'm inclined to agree with you about it being a kernel problem, which is why I blacklisted my wireless driver in the first place. I would have checked dmesg by now, except that my first reaction to the problem was always to reboot, and it never occurred to me to check my logs after the fact. Fortunately, they go pretty far back: I've attached a log of an entire boot that I'm pretty sure included this bug, there's no other reason I would have rebooted the machine on a Monday morning. There doesn't seem to be anything in there that clearly reveals the cause, but there is some suspicious stuff at the end that may be of use to someone familiar with the corresponding source code.