Description of problem: running anything with sudo auth cached is slow! Version-Release number of selected component (if applicable): Rawhide (installed Preview CD to disc) How reproducible: run anything with sudo for the second time (so it doesn't ask for a password) like sudo vim /etc/ddclient.conf Steps to Reproduce: 1. uncomment the "%wheel ALL=(ALL) ALL" line in /etc/sudoers 2. add yourself to the wheel group (I used system-config-users as root) 3. run anything, like f.ex. sudo vim /etc/ddclient.conf 4. enter your password 5. now exit vi and use sudo to do "something else" Actual results: a 10 second wait Expected results: immediately run "something else" Additional info: how can I send you guys more useful debugging info? is this due to me changing the laptop's hostname to a dyndns one?
Hi, could you please try the new build? (https://admin.fedoraproject.org/updates/sudo-1.7.1-1.fc11)
IT's still kinda slow... how can I more accurately help you debugging this?
i confirm the issue: sudo is very slow, quite impossible to work with it
Ok. The output of strace would be helpful. Here is the command: # strace -u <user> -Tvxf -o strace.log sudo cmd You'll have to run this command as root (or set +s on strace). Substitute <user> with the user name under which you want to run the "sudo cmd" part. It'll write the output into strace.log. Attach this file to this bug report please.
Created attachment 345444 [details] strace.log the command is: strace -u tommyblue -Tvxf -o strace.log sudo cat .bashrc
(In reply to comment #5) > Created an attachment (id=345444) [details] > strace.log > > the command is: > strace -u tommyblue -Tvxf -o strace.log sudo cat .bashrc Thanks. Do you have a record with your hostname (nerina?) in /etc/hosts? uname({sysname="Linux", nodename="nerina", release="2.6.29.3-155.fc11.i686.PAE", version="#1 SMP Wed May 20 17:31:09 EDT 2009", machine="i686"}) = 0 <0.000007> ... ... socket(PF_INET, 0x802 /* SOCK_??? */, IPPROTO_IP) = 5 <0.000012> connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("208.67.222.222")}, 28) = 0 <0.000013> ... ... ... poll([{fd=5, events=POLLIN}], 1, 4887) = 0 (Timeout) <4.891569>
no, this is /etc/hosts as created by the installer: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
208.67.222.222 is the address of opendns, used by my router
(In reply to comment #7) > no, this is /etc/hosts as created by the installer: > > 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 But you've set "nerina" as your hostname, haven't you? If this is true then add a record for "nerina" into /etc/hosts and then try sudo again.
with the hostname set, sudo seems to work faster. But why the hostname wasn't set in /etc/hosts? i typed it during the install, maybe a bug in anaconda?
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Yes by adding my hostname to /etc/hosts I reduced my wait from ~30-60 seconds to < ~1.5 seconds for sudo to execute. Happy Happy joy joy. So: 1. Does a work around exist for DHCP users who would require change for each new IP to /etc/hosts? I never had this issue before with any other version of Linux (including any other Fedora Core (X) installs. This is why I am adding to this bug report (498749) which appears to have been closed/redirected above in comment 11....? Thanks.
(In reply to comment #12) > 1. Does a work around exist for DHCP users who would require change for each > new IP to /etc/hosts? It should be fine when using DHCP. I'm using DHCP on F10 (NetworkManager) and the records are there. > This is why I am adding to this bug report (498749) which appears to have been > closed/redirected above in comment 11....? This bug is still open. But I don't think that this is something that should be fixed in sudo. The hostname of your machine should be resolvable.
*** Bug 519084 has been marked as a duplicate of this bug. ***