Why does sudo command take long to execute?

Question

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.

Technically this counts as editing a script, right? Isn't a script a program? — , Jul 09 '09 at 04:29
NOPASSWD: is considered a security risk and defeats the purpose of having to use sudo in the first place. — , Jul 09 '09 at 04:43
I can buy that, but the issue still remains as to why it takes so long. — , Jul 09 '09 at 05:08
Where does this machine get is users and authentication from? LDAP, possibly with Kerberos perhaps? — wzzrd, Jul 09 '09 at 06:31
Possible duplicate of [Every single time I use sudo it hangs before completing](http://serverfault.com/questions/65370/every-single-time-i-use-sudo-it-hangs-before-completing) — Harry Tsai, Sep 07 '16 at 15:28
Facing the same issue, with or without `NOPASSWD` (also irrelevant advice in reference to the question). — FractalSpace, Dec 11 '17 at 17:21

score 182 · Accepted Answer · edited May 15 '15 at 10:03

182

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>

edited May 15 '15 at 10:03

masegaloeh

18,236
10
57
106

answered Jul 16 '09 at 19:56

Cuga

101
3
4
11

3

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 05 '09 at 00:43
1

This fixed my slow sudo usage, thanks! I edited /etc/hostname, and just forgot to edit the /etc/hosts file. – Joe May 04 '11 at 15:10
2

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
1

It can also be /etc/nsswitch.conf (for similar reasons). Mine was set to "hosts: dns files" and so it was looking up my hostname on a DNS server with a long timeout. I changed it to "hosts: files dns" and so now it'll look in /etc/hosts first. Thanks for this answer, which led me to look in nsswitch.conf! – Alan Porter Mar 19 '15 at 16:12
4

That's ridiculous that this was the solution. Why in the world does the `sudo` command have to look at the hostname in order to work? What does my hostname have to do with `sudo echo hello`? Anyways, thanks for the answer – smac89 Nov 15 '18 at 17:30
I am running CentOS 6.x and the issue has been `rsyslog` needing to be restarted. Full answer below from @galgalesh – gillytech Nov 25 '18 at 03:17
To avoid the delay when editing /etc/hosts, you can run `sudoedit -h localhost /etc/hosts` (or `sudo -h localhost vi /etc/hosts` or whatever if you don't have $EDITOR set). – Ray Dec 08 '18 at 21:34
Why does sudo do this? Because it's multiuser configuration can be set by host. You can disable this with a `Defaults !fqdn` careful if you are actually relying on hostnames in sudoers instead of ALL – Ray Foss Feb 05 '21 at 20:22
I have tried this and it didn't resolve the issue for me with Centos 7 in AWS instances. Is it possible we should try restarting some service to apply the change? – openCivilisation Feb 13 '21 at 02:46

score 28 · Answer 2 · edited Sep 02 '16 at 07:53

28

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

Run the following command

logger 'Hello world'

Does the command return within a reasonable amount of time?
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.

edited Sep 02 '16 at 07:53

Merlijn Sebrechts

469
1
5
16

answered Feb 17 '14 at 14:25

MattB

756
7
5

10

Surprisingly that was the problem for me. Who would have thought it. The solution for me was just to restart syslog. `service rsyslog restart` – MikeKulls Nov 25 '15 at 10:34
Same here. `service rsyslog restart` fixed my slow sudo commands. – Pedro Cordeiro Sep 02 '16 at 16:54
Surprisingly that was the problem for me. Before that, the whole request for the server is so slowly. I just want to know why? – michael wang May 08 '17 at 06:43

score 15 · Answer 3 · answered Jul 09 '09 at 03:58

15

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

answered Jul 09 '09 at 03:58

ysth

129
1
10

Thx. This is on the HDD tho, no USB or network drive. – Jul 09 '09 at 04:27
@Cuga: and what did you learn from strace? – Jul 09 '09 at 04:41
@oligofren: you need to do sudo strace – ysth May 04 '15 at 21:41

score 12 · Answer 4 · answered Mar 29 '13 at 18:48

12

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.

answered Mar 29 '13 at 18:48

mdpc

11,856
28
53
67

Best answer (for me)! Found out my DBus Broker was crashing on network disconnect and sudo/KDE was timing out on connecting to it. Thanks! – PSSGCSim Jul 13 '19 at 07:21
Thanks, this helped me. I also had to undo a previous change to the `hosts` line in my /etc/nsswitch.conf. I had added "resolve dns" as a prefix to the `hosts` value. When I removed this prefix, sudo was fast again. – mnieber Jul 16 '19 at 07:33

score 7 · Answer 5 · answered Nov 25 '14 at 13:09

7

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.

answered Nov 25 '14 at 13:09

Sakuraba

101
1
1

Why do you post an obviously unrelated answer (the OP didn't use LDAP) to a five year old question? – Sven Nov 25 '14 at 13:15
7

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 '14 at 10:48
6

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 '14 at 10:51

score 5 · Answer 6 · answered Jul 09 '09 at 04:37

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.

score 5 · Answer 7 · edited Jun 15 '21 at 16:00

5

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.

edited Jun 15 '21 at 16:00

Community

1

answered Aug 19 '14 at 08:05

Zahid Hussain

1
1
1

score 3 · Answer 8 · answered Aug 06 '09 at 02:18

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.

score 3 · Answer 9 · edited Apr 13 '17 at 12:14

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

Thank you for this piece of information. From the information here, I was then able to find a [related article](http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0102049) that noted the possibility of `fprintd` (the fingerprint authentication) the culprit. Removing `fprintd` and `fprintd-pam` resolved the issue for me. — KevinO, May 17 '17 at 19:44
@KevinO Pleased that it helped you to find a solution. I knew however that my problem was very specific and that my contribution to the question should be only the method how to diagnose or exclude a suspicion about SELinux. — hynekcer, May 17 '17 at 22:49
I absolutely gave it a +1! It was the message bus that led to a solution. I had looked a couple of times on sudo slow, but yours was the clue I needed. — KevinO, May 18 '17 at 01:19

score 2 · Answer 10 · answered Jul 09 '09 at 12:24

2

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

(source)

answered Jul 09 '09 at 12:24

Ryan Emerle

163
1
1
5

score 1 · Answer 11 · answered Sep 14 '22 at 08:48

Using strace pointed me to dbus.

# Run strace with timestamp and output file 
strace -t -o /tmp/strace.txt sudo ls

In the output file, I see a connect call to file /run/dbus/system_bus_socket, and a Timeout message with the same file descriptor fd=7

10:20:16 connect(7, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 29) = 0
...
10:20:16 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout)                                                                                                                                                     
10:20:41 sendmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1\204\0\0\0\6\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="\177\0\0\0type='signal',sender='net.re"..., iov_len=132}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 276

Password prompt appeared at 10:20:41, 25 seconds after command is run. Restarting messagebus service fixed the issue:

systemctl restart messagebus

I have this error `sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?` — nowox, Nov 17 '22 at 14:32

score 1 · Answer 12 · answered Jul 09 '09 at 04:04

1

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

answered Jul 09 '09 at 04:04

C. K. Young

1,862
16
16

I added a space, but it still has the lag. Thx for the suggestion. – Jul 09 '09 at 04:35

score 1 · Answer 13 · edited Feb 12 '13 at 05:35

1

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

edited Feb 12 '13 at 05:35

slm

7,615
16
56
76

answered Feb 12 '13 at 05:14

Roger Smith

1
1

score 1 · Answer 14 · answered Apr 01 '13 at 18:19

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.

score 0 · Answer 15 · answered Jul 09 '09 at 07:25

0

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

answered Jul 09 '09 at 07:25

jtimberman

7,587
2
34
42

score 0 · Answer 16 · answered Jul 09 '09 at 12:57

0

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

answered Jul 09 '09 at 12:57

towo

1,887
14
12

score 0 · Answer 17 · answered Sep 24 '19 at 15:29

Systemd Case

For me, my system had run out of memory and a lot of processes crashed. My system is based around systemd and something in there had crashed. It's hard for me to remember everything I did, but:

systemctl status <any.service> would timeout
I couldn't sudo reboot (systemd based)

Solution

A restart fixed my issue, but for me was just a bandaid. You still need to find out why you ran out of memory/crashed.

Why does sudo command take long to execute?

17 Answers17

SELinux case

Linked