On my Ubuntu 9.10 server at home, I had been having a hard-to-diagnose problem where the “sudo” command will pause for 20 seconds before getting on with its business.

What made this problem so hard to track down is that it would happen once, and then the log jam would be cleared for a while. I would usually see it the first time I issued a sudo command, but never again in that session. The next day, it would do it again.

Last night, I finally tracked the problem down.

What helped the most was the discovery that I could do “sudo -K” to make sudo “forget” my earlier authentication. When I re-tried to run a sudo command, it would prompt for a password and then delay 20 seconds… every time.

So now I had a way to test out theories. I just needed some theories to test.

I saw many reports on the internet about Fedora users seeing a similar issue. Their problem turned out to be in the /etc/hosts file — there were problems if “localhost” and “localhost.localdomain” and even the machine’s given hostname were not listed there. But this was not the case for me. My hosts file was fine.

Instead, I started tracing what happens when sudo is called (unfortunately, you can’t just “strace sudo somecommand“, because strace does not like to trace a setuid program).

I looked at PAM, the pluggable authentication modules. In the /etc/pam.d directory, there was a file called “sudo”. This did not have anything interesting in it. But it did include a couple of other files: “common-auth” and “common-account”. It turns out that the last line in the common-auth file was the culprit:

auth  optional  pam_ecryptfs.so  unwrap

This line is supposed to decrypt the user’s home directory if is encrypted, so it can read the files as part of sudo’s startup. But I don’t have any encrypted home directories. So for me, this is unnecessary.

Commenting out this line made the 20-second delay go away.