Bug 126663 - Resolver delays on unconnected laptop
Resolver delays on unconnected laptop
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-24 10:43 EDT by Göran Uddeborg
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:23:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Göran Uddeborg 2004-06-24 10:43:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.4.2)
Gecko/20040301

Description of problem:
On an unconnected laptop, trying to look up using the resolver takes a
considerable delay.  Connecting a laptop to a network makes can make
it change its name to something which is only remotely resolvable. 
After disconnecting it again, apparently unrelated programs like emacs
takes long to start since they wait for a resolver timeout.

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

How reproducible:
Always

Steps to Reproduce:
1. Start a laptop without any network
2. Run "emacs".
3. Connect laptop to network
4. Run "emacs".
5. Take the network interface down again
6. Run "emacs".

Actual Results:  The third emacs invocation has a significantly slower
startup.

Additional info:
Emacs apparently wants to look up the local hostname.  Initially, this
is "localhost".  When connecting the laptop, it sets its hostname. 
This hostname is not known locally, but requires a DNS lookup.  When
disconnecting again, the host name remains the one found out with DHCP
during connection.  But now, this name can no longer be looked up.

Doing an strace of a command reveals it is doing a sendmsg call to the
DNS server, and then waits for a reply.  However, the return code for
the sendmsg call is an error (ENETUNREACH).  It seems it would make
sense to return immediately in this case; if the question could not be
sent, there is not much point in waiting for an answer.  Would this be
hard to do?  I tried to take a look in the resolver code, but I get
lost among all the defines.
Comment 1 Suzanne Hillman 2004-08-09 11:37:42 EDT
Internal RFE bug #129472 entered; will be considered for future releases.
Comment 2 RHEL Product and Program Management 2007-10-19 15:23:28 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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