Whether I get prompted for a password or not, it hangs between accepting the authentication and executing what I asked for. In other words sudo ls
will hang for about 60 seconds.
I'm confused about what might be causing this. This is on Centos 5, and I've looked at selinux
and set it both to disabled and enabled, but it doesn't seem to have any effect.
From @TheAndruu's answer to this question:
This happens if you change the hostname during the install process. To solve the problem, edit the file /etc/hosts
I had exactly the same problem on Fedora 11 and this solved it.
Sometimes when your default route isn't set, commands like sudo hang.
Try
netstat -r
to check if the route is set correctly.Does this machine get its passwords from the local /etc/passwd file or something like ldap?
The only other thing you may want to check is your /etc/resolv.conf file to make sure you have a proper dns entry in there. I have seen in the past where this can cause delay.
You should check three things. 1. /etc/hostname 2. /etc/hosts 3. /etc/resolv.conf
I found that my hostname was correct that the hosts file was incorrect and on top of that the resolv.conf needed updating.
For me it was krb5-user/config being installed. I noticed this by examining /var/log/auth.log and seeing pam_krb5 attempts before pam_unix. Using apt-get remove to uninstall those packages fixed it. Don't remove those packages if you are on a computer requiring kerberos (pam_krb5) obviously. My sudo hang went from a consistent 30s to 0s.
This is hinted at in Halsafar's answer, I have Kerberos enabled on my work VPN but it's useless when I'm off it, so I changed the auth module order in
/etc/pam.d/common-auth
to usepam_unix
beforepam_krb5
:Before:
After:
This changed my sudo from 30s to 0s as it did in Halsafar's answer.
On Solaris 10 sudo was hanging for about 30 seconds. With help from truss I was finally able to determine that it was hanging on the quota command which was hanging on an NFS mount. Unmounting the NFS share eliminated the hang. Have not determined what is wrong with the share yet.
In Fedora 30, Snapd causes sudo, su, etc, to become very slow, and also other session related problems.
Uninstalling snapd, if you're at Fedora, is a recommended alternative.