Sudo Hangs Indefinitely Without Prompting for Password

sudo

When I logged back into my Ubuntu desktop after an update, my display driver was seemingly unavailable and I was met with vt-7's output. I changed to a different terminal and logged in. However, when I attempted to use sudo to install a display driver, sudo hung forever. No prompt for a password, Ctrl+c Ctrl+d Ctrl+z all didn't do anything. It ate my virtual terminal. I changed to another one and the same thing happened. What's happening?

Update

/etc/pam.d/sudo

#%PAM-1.0
auth required pam_env.so readenv=1 user_readenv=0
auth required pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive

Other commands such as ifconfig also seem to hang.

Update 2

I think that this breakage has to do with the fact that Ubuntu tried to upgrade a kernel with an earlier verison. I was running kernel 3.7.1 which I downloaded and installed manually, and Ubuntu did a dist-upgrade which "upgraded" the kernel to 3.2.X. I have a feeling that this messed things up substantially. I'm going to try reinstalling the kernel and see if I can undo some of the fallout. Note to self: always disable Ubuntu kernel updates when running a later kernel.

Best Answer

A kernel "upgrade" was the cause of this calamity. Since I installed my own, later kernel from kernel.ubuntu.com, when a "new" kernel of a different minor version was installed, everything in the world got messed up.

For my purposes, I had manually installed kernel 3.7.1, whereas the kernel provided by the Ubuntu distribution is kernel 3.2.0. This, for some reason, really botched things up, despite the fact that I was running 3.7.1 from an EFI boot and there simply isn't a way to boot into kernel 3.2.0. There are incompatibilities between kernel versions and the wireless driver, but an incompatibility with the wireless driver wouldn't cause everything to lock up and get messed up.

Next step for completely solving the problem would be completely preventing kernel updates from ever happening again. How can I do this? I've heard of doing it with dpkg --set-selections, but I'm not sure how to prevent updates to all linux-(headers,headers-generic,image,image-extra) packages, due to their naming:

linux-headers-3.2.0-36
linux-headers-3.2.0-36-generic
linux-image-3.2.0-36-generic

How do I block changes to all kernels starting with 3.2?

Related Solutions

Why sudo Command Executes Without Prompting for Password

Say sudo -K, then retry your test. If it starts asking again, all that was happening is that you had sudo configured to remember your password for some time.

On top of this, Ubuntu's default sudo configuration makes it remember your credentials across ttys. This affects ssh sessions, as you've discovered, since each new ssh connection looks like a new terminal to the low-level OS code.

This also affects things like the graphical Terminal app. If you authenticate with sudo, then create a new tab with Ctrl-Shift-T, you'll find that you don't need to give a password to sudo again in that tab, despite the fact that it also creates a new tty. You can even close the Terminal app entirely, and as long as you restart it within the normal password timeout, sudo will run without requiring you to re-enter your password. This behavior may be enough to make you decide you want to keep this feature enabled.

Mac OS X works this way these days, too.

Not all *ixes do. Red Hat Enterprise Linux (and derivatives like CentOS) insist on getting the password on each new tty.

You can disable both behaviors by changing the Defaults line in /etc/sudoers to something like this:

Defaults=env_reset,timestamp_timeout=0,tty_tickets

The env_reset bit should be there already, and isn't relevant here
The timestamp_timeout directive tells it to immediately time out each sudo session. It's like saying sudo -K after every normal sudo command.
The tty_tickets directive ensures that it associates credentials with the tty they were used on, not just the user name. This is supposed to be the default already, and is documented as such on Ubuntu, but they must have built their distribution of sudo to disable this option, for the convenience reasons given above.

Bash – sudo command after long sleep call without re-prompting sudo password

As Mat suggested, you can allow the user to run pm-suspend without a password.

Run sudo visudo

Add youruser ALL=(root) NOPASSWD: /path/to/pm-suspend