Bug 496236 - "sudo -i" can take up to 40 seconds to provide prompt. (issue with non-resolvable hostnames?)
"sudo -i" can take up to 40 seconds to provide prompt. (issue with non-resolv...
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Kopeček
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-17 09:48 EDT by Tom London
Modified: 2009-04-23 09:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-23 09:11:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from "strace -ttt -o sudo-home.txt sudo -i" (590.55 KB, text/plain)
2009-04-17 09:48 EDT, Tom London
no flags Details

  None (edit)
Description Tom London 2009-04-17 09:48:22 EDT
Created attachment 340010 [details]
Output from "strace -ttt -o sudo-home.txt sudo -i"

Description of problem:
I have a laptop that I "named" during install as "tlondon.innopath.com"

If I run "sudo -i" from gnome-terminal when the laptop is connected "at work" (i.e., innopath.com), "sudo -i" produces root prompt within a second or two.

On the otherhand, if I do the same from "at home" (i.e. Comcast) where "tlondon.innopath.com" doesn't resolve to anything interesting, "sudo -i" takes about 30-40 seconds to produce the root prompt.

I ran "strace -ttt -o sudo-home.txt sudo -i" and attach the output.

From my (naive) scan, looks like it is hanging on "recvfrom"s like the following (DNS?):

socket(PF_INET, 0x802 /* SOCK_??? */, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, 28) = 0
poll([{fd=5, events=POLLOUT}], 1, 0)    = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\21\302\1\0\0\1\0\0\0\0\0\0\7tlondon\10innopath\3com"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
poll([{fd=5, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\220\245\1\0\0\1\0\0\0\0\0\0\7tlondon\10innopath\3com"..., 38, MSG_NOSIGNAL, NULL, 0) = 38
poll([{fd=5, events=POLLIN}], 1, 4999)  = 1 ([{fd=5, revents=POLLIN}])
ioctl(5, FIONREAD, [38])                = 0
recvfrom(5, "\220\245\201\200\0\1\0\0\0\0\0\0\7tlondon\10innopath\3com"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, [16]) = 38
poll([{fd=5, events=POLLIN}], 1, 4898

This a legitimate use case?

Version-Release number of selected component (if applicable):

How reproducible:
Every time.....

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Tom London 2009-04-22 09:49:17 EDT
I am no longer seeing this delay....

I believe I noticed it yesterday.

I'm not sure "what changed"; I've been keeping system "rawhide up to date".....

If this does not reappear in a day or so, I'll close....
Comment 2 Tom London 2009-04-23 09:11:56 EDT
I can no longer reproduce this.


Note You need to log in before you can comment on or make changes to this bug.