Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've been picking up Linux (Fedora 10, then 11) over the past few months (and enjoying it immensely-- it's like discovering computers all over again, so many things to learn).

I've added my user to the last line of the /etc/sudoers file as shown below, so that I don't get asked for my password when I execute the sudo command:

MyUserName ALL=(ALL) NOPASSWD:ALL

Now every time I execute a command using sudo, it pauses a noticible amount of time before actually performing the task (~10 seconds). Why might this be and how might I fix this? I'm running Sudo version 1.7.1 on Fedora 11 x86 64.

share|improve this question
    
Technically this counts as editing a script, right? Isn't a script a program? –  Cuga Jul 9 '09 at 4:29
4  
NOPASSWD: is considered a security risk and defeats the purpose of having to use sudo in the first place. –  LiraNuna Jul 9 '09 at 4:43
    
I can buy that, but the issue still remains as to why it takes so long. –  Cuga Jul 9 '09 at 5:08
2  
Where does this machine get is users and authentication from? LDAP, possibly with Kerberos perhaps? –  wzzrd Jul 9 '09 at 6:31

14 Answers 14

I asked this question over on SO and it got moved here. That said I no longer have the ability to edit the question as if I owned it, or even accept the correct answer, but this turned out to be the true reason why and how to solve it:

Found here User "rohandhruva" on there gives the right answer:

This happens if you change the hostname during the install process.

To solve the problem, edit the file /etc/hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>
share|improve this answer
2  
Quite right. Somewhat surprising that distros like Fedora don't edit /etc/hosts if you change your hostname at install time, but whatever. That's open source for you! –  dimo414 Aug 5 '09 at 0:43
    
This fixed my slow sudo usage, thanks! I edited /etc/hostname, and just forgot to edit the /etc/hosts file. –  Joe May 4 '11 at 15:10
    
Adding your Hostname to the 127.0.0.1 or ::1 line can cause certain server related software from binding to the right Hostname/IP/interface. One such example is Cloudera Manager, the hadoop services get the wrong Hostname and confuse CM because they all resolve to localhost. I suggest reading other answer below for a possible solution. This may or may not cause issues to a standalone workstation which will have no other computers connecting to it. –  ddcruver Dec 22 '13 at 22:14

Is one of the files/directories it needs to read on a networked mount, or is it somehow triggering reading from a slow usb device? Try strace and see where it's slow; if it goes by too fast, do

sudo strace -r -o trace.log sudo echo hi

Each line will start with the time taken since entering the previous syscall.

(The initial sudo seems to be necessary; I don't know how much that will perturb the results.)

share|improve this answer
    
Thx. This is on the HDD tho, no USB or network drive. –  Cuga Jul 9 '09 at 4:27
    
@Cuga: and what did you learn from strace? –  ysth Jul 9 '09 at 4:41

I'm not sure about Fedora, but I've used other systems where sudo would check where you're logged in from, which if your DNS isn't set up well can take ages to timeout. This can also be seen when SSH'ing in to the machine - it takes ages to come up with a prompt.

share|improve this answer

I recently found that I had the same problem. There had been no sudo delay and then all of a sudden, about a 10-20 second delay. I determined the specific issue using:

 1. chmod u+s /usr/sbin/strace  (as the root user)

As yourself:

 1. sudo -K
 2. strace sudo /bin/tcsh

And then find where the system calls are hanging.

In MY case, I found that it was hanging on a DNS translation, apparently one of the DNSen in my list on /etc/resolv.conf was very buzy or gone bad. So I changed the resolution order and poof things worked quickly again.

share|improve this answer

Check that your syslog daemon is working correctly; this caused the issue for me.

For example, does logger 'Hello world' return within a reasonable amount of time?

share|improve this answer

In may case, it is found the hostname (that was configured in /etc/sysconfig/network) doesn't exist in /etc/host file; so upon adding in afore-mentioned file, the file opens promptly

share|improve this answer

From looking at the sample sudoers file I have, I believe there is supposed to be a space after the NOPASSWD: bit.

share|improve this answer
    
I added a space, but it still has the lag. Thx for the suggestion. –  Cuga Jul 9 '09 at 4:35

I had a similar problem, I fixed it by placing both the hostname (e.g. mybox) and the full output of the hostname command (mybox.mydomain.com). This cleared it right up. Went from 2 minutes to open /etc/hosts to instantaneous access.

share|improve this answer

After fixing any host problems make sure you clear any bad DNS cache if you are running a DNS caching application like nscd:

/etc/init.d/nscd force-reload
share|improve this answer

Are you using LDAP for authentication?

If so you probably want to use bind policy soft. In /etc/ldap/ldap.conf (or /etc/ldap.conf):

bind_policy soft
share|improve this answer

Check your /etc/hosts file and make sure you have an entry for 127.0.0.1

(source)

share|improve this answer

Sounds like you have some kind of timeout in your authentication chain. Check how sudo tries to authenticate and watch for bottlenecks.

share|improve this answer

For me it was krb5-user/config/locales being installed. I noticed this by examining /var/log/auth.log. 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.

share|improve this answer

I hade the same problem, I checked /var/log/auth.log and syslog for errors. Turns out that my LDAP server could not be reached and it slowed down everything.

I did not use LDAP based auth anymore, so I removed all "ldap" references from /etc/nsswitch.conf

Since then everything works like a charm again.

share|improve this answer
    
Why do you post an obviously unrelated answer (the OP didn't use LDAP) to a five year old question? –  Sven Nov 25 at 13:15
    
Because it might help anyone. I checked all the things that were mentioned here, but nothing helped. Someone else might be focused into looking into the right direction with my answer by checking whether he has any LDAP connection issues as the underlying reason of the slow and unresponsive sudo command. It is as relevant as the DNS-related answers in that something behind the covers is at fault which is not directly visible to the user. I consider this site as a general source of knowledge and not just as a single question/answer type of website. It is about collecting relevant knowledge. –  Sakuraba Nov 26 at 10:48
1  
Also who in the blue hell are you to discredit my help. This site works because sharing knowledge is incentivized, not because people are downvoted. If you dont like it, then you entitled to ignoring it. –  Sakuraba Nov 26 at 10:51

protected by Sven Nov 25 at 13:13

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.