Home / server / Questions / 38114
Accepted
4 revs, 3 users 40%anon
Asked: 2009-07-09 19:51:12 +0800 CST

Why does sudo command take long to execute?

  • 772

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 noticeable 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.

linux permissions sudo

16 Answers

  1. Best Answer

    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>
    • 173

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

    Run the following command

    logger 'Hello world'

    1. Does the command return within a reasonable amount of time?

    2. Does 'Hello world' show up in /var/log/syslog?

    If this is not the case, the syslog daemon has crashed. Restarting it should fix your problem.

    • 28

  3. 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.)

    • 13

  4. 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.

    • 11

  5. 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.

    • 7

  6. 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.

    • 5

  7. In my case, the hostname (that was configured in /etc/sysconfig/network) didn't exist in /etc/hosts file; so upon adding it to the aforementioned file, the file opens promptly.

    • 5

  8. 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.

    • 3

  9. SELinux case

    If the same sudo command is slow only in a daemon and fast on the command line, then it is caused by SELinux the most probably. (SELinux = NSA Security-Enhanced Linux kernel module, enabled in Fedora by default.)

    A typical case is a http server and a special script for server management, restricted in sudoers:

    apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command

    It is typical in this case that nothing about SELinux is reported in the audit log ausearch -m avc -ts today, but the script is going fast if we temporarily disable enforcing by setenforce 0. (and then back enable by setenforce 1)

    The only relevant messages in the system log (journalcrl) are these after the delay 25 seconds:

    ... sudo[...] pam_systemd(sudo:session): Failed to create session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
    ... sudo[...]: pam_unix(sudo:session): session opened for user root by (uid=0)

    Logging of all silented "dont-audit" SElinux messages can be enabled by semodule -DB and disabled again by semodule -B.
    (I hope that I write soon a SELinux policy module soon for this case here or a method from this answer can be used.)

    • 3

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

    (source)

    • 2