|slow hostname resolution / resolver behavior||Jules Richardson||12/26/12 5:10 PM|
I just put slack 14.0 onto my laptop, and noticed that 'hostname -f' (as
called by the startx script) was taking a little over 20 seconds to run
whenever the machine wasn't connected to a network (which is how I often
Deleting/renaming /etc/resolv.conf 'fixes' it, in that it will then
immediately return with the DNS domain name (and hostname) that is set
in /etc/hosts - but of course it would be nice to just leave resolv.conf
in place for those times when I do have the system connected to the LAN.
I've got "order hosts, bind" in /etc/host.conf and "hosts: files dns"
in /etc/nsswitch.conf (as per install defaults), so my understanding was
that this should be enough to make it hit /etc/hosts first before trying
to contact any nameserver out on the LAN at all - obviously I'd get the
delay (and a resolver error) for anything that wasn't in /etc/hosts, but
for a local machine lookup using 'hostname -f' it should be OK.
In fact, I've got a system running slack 13.1 and have cross-checked
files (nsswitch.conf, hosts, host.conf, resolv.conf) against this - it's
set up in exactly the same way (barring hostname and IP address
differences, of course) and behaves exactly as I'd expect when invoking
'hostname -f', resolving the local machine's hostname and DNS domain name
from /etc/hosts immediately, even though resolv.conf is present.
So... am I missing something obvious (probably! :-) that's telling the
machine to always try contacting the LAN nameserver first? Can someone
with slack 14.0 check for me to see if their system behaves the same when
running hostname -f with their Ethernet cable disconnected?
|Re: slow hostname resolution / resolver behavior||Henrik Carlqvist||12/27/12 3:45 AM|
On Thu, 27 Dec 2012 01:10:45 +0000, Jules Richardson wrote:I don't have Slackware 14, but I also have a Slackware 13.1 install and
did a quick test:
$ strace hostname -f |& grep open
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY) = 3
open("/etc/resolv.conf", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libnss_files.so.2", O_RDONLY) = 3
open("/etc/host.conf", O_RDONLY) = 3
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
Even though I have "hosts: files dns" in nsswitch.conf and
"order hosts, bind" in host.conf on my Slackware 13.1 system
/etc/resolv.conf is read before any of those files are opened.
However, I guess that it only reads the file to get the domain line, my
hostname does not try to connect any DNS server listed in that file.
What does your /etc/HOSTNAME look like? What does the line in /etc/hosts
look like? What does the domain line look like in resolv.conf?
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
|Re: slow hostname resolution / resolver behavior||Jules Richardson||12/27/12 4:00 PM|
On Thu, 27 Dec 2012 11:45:01 +0000, Henrik Carlqvist wrote:Yes, I've just confirmed that my slack 13.1 system does the same - as
does the 14.0 machine.
Here's all the relevant stuff from the 14.0 system:
order hosts, bind
hosts: files dns
192.168.2.16 moa.foobar.org moa
All files have permissions set to 644 and are owned by root. The setup
seems to be exactly the same as I have on the 13.1 system, where
'hostname -f' will return immediately even if the network cable is
unplugged, and will pull the host and DNS domain name from /etc/hosts.
Note that I don't explicitly set the domain name in resolv.conf on either
system (this is the slack installer/setup default), but I tried adding it
and it makes no difference to the behavior (on either machine) anyway.
|Re: slow hostname resolution / resolver behavior||Henrik Carlqvist||12/28/12 4:18 AM|
On Fri, 28 Dec 2012 00:00:35 +0000, Jules Richardson wrote:If you run strace without the grep you will get a lot of output. In that
output you will also see if and when any socket is connected to the DNS
server. However to avoid having all the noise scrolling the terminal
window it might be a good idea to redirect the output to a file:
strace hostname -f >& /tmp/test.txt
As far as I can tell all the files look OK. But maybe there is some other
difference between the 13.1 and 14 system. What about ifconfig? With the
network cable disconnected, does both systems still have address
192.168.2.16 assigned to something like eth0?
|Re: slow hostname resolution / resolver behavior||Jules Richardson||12/28/12 1:54 PM|
On Fri, 28 Dec 2012 12:18:44 +0000, Henrik Carlqvist wrote:Yes - and the output on the two machines looks to be very similar (same
files opened in the same order etc.) until the end, when the 14.0 system
does indeed try to contact the DNS server on my LAN. Eventually it gives
up on that, opens /etc/hosts, and gets the domain name from there.
Thanks for checking. They seem fine to me, too; it's as though the 14.0
system is just completely ignoring the query order that's defined in
host.conf (and nsswitch.conf).
Yes, eth0 shows up in ifconfig on the 14.0 system whether the cable is
connected or not, and this is the same behavior as I get with the 13.1
The only possibility I've thought of so far is that the 14.0 system has a
wireless interface too. I've not configured it (so it doesn't show up in
ifconfig output etc.) but the kernel does detect it at boot time and load
the relevant Broadcom module. I wonder if there's some bug/quirk/feature
of the resolver library which is triggered on a system with multiple LAN
interfaces (even if one or more of those interfaces isn't set up)? That
seems like a long shot, but I really can't see anything wrong with the
config files which would explain things.
|Re: slow hostname resolution / resolver behavior||Henrik Carlqvist||12/29/12 4:00 AM|
On Fri, 28 Dec 2012 21:54:54 +0000, Jules Richardson wrote:The reason that I asked is that I have seen Slackware 13.1 systems which
accidentaly got the wicd security patch installed shutting down eth0 when
the cable was disconnected. Reconnecting the network cable still resulted
in a system without eth0 configured.
As everything seems OK with your 14.0 system the only thing that remains
to blame is hostname.
Compare the output of
on both systems.
You could also try to copy the hostname binary from the 13.1 system to
some place on the 14.0 system like /tmp and see how the old binary
behaves on the new system.
|Re: slow hostname resolution / resolver behavior||Jules Richardson||12/30/12 7:32 PM|
On Sat, 29 Dec 2012 12:00:18 +0000, Henrik Carlqvist wrote:Well that's interesting - it's exactly the same on 13.1 and 14.0: net-
tools is 1.60 and hostname is 1.100 (dated 2001-04-14).
Even more interesting, the man page for hostname on 13.1 and 14.0 both
says "The FQDN is the name gethostbyname(2) returns for the host name
returned by gethostname(2)." (with the FQDN being everything after the
So, I threw some quick C code together to call gethostbyname() and return
the FQDN. It works fine on both systems *and it returns instantly on the
14.0 machine* - no delays or calls out onto the (unplugged) LAN.
Whatever the fault is on 14.0, it doesn't seem to be with gethostbyname()
(assuming that the man page text is correct), but for some reason
'hostname -f' on 14.0 is still trying to contact the LAN's DNS server,
even though gethostbyname() is returning the full system name.
Next step might be to have a look at the source for hostname on 14.0...
|Re: slow hostname resolution / resolver behavior||Henrik Carlqvist||12/31/12 3:44 AM|
On Mon, 31 Dec 2012 03:32:09 +0000, Jules Richardson wrote:Are you able to run the 13.1 hostname binary on Slackware 14.0? If so,
that would be a quick and easy test.
|Re: slow hostname resolution / resolver behavior||Jules Richardson||12/31/12 11:29 AM|
On Mon, 31 Dec 2012 11:44:47 +0000, Henrik Carlqvist wrote:Yes... and 13.1's hostname works on the 14.0 machine as expected, and
returns immediately with the fqdn.
Looking at the source, it seems to be an IPv6 thing - slack 13.1's
hostname looks to be compiled without IPv6 support and 14.0's is compiled
with. With IPv6 support, hostname will call gethostbyname() *and*
gethostbyname2(), but with IPv4 support it will only call
gethostbyname() returns immediately, but IPv6-friendly gethostbyname2()
ignores the host.conf order and goes straight to trying to contact the
DNS server on the LAN. That's perhaps correct, as I don't think there's a
way to put IPv6 addresses into /etc/hosts, so IPv6 lookups have to
contact a DNS server somewhere - but in this particular case where all we
want is the FQDN it would be nice if it honored host.conf and pulled the
data from /etc/hosts if the system was configured that way.
It's an interesting problem, anyway (I wouldn't quite call it a bug :-)
|Re: slow hostname resolution / resolver behavior||Jules Richardson||12/31/12 12:54 PM|
On Mon, 31 Dec 2012 19:29:09 +0000, Jules Richardson wrote:OK. It seems that /etc/hosts *can* accept IPv6 addresses (the man page
just doesn't make this obvious, and the examples are all IPv4 format).
If I add a temp entry to /etc/hosts of the form:
::1 moa.foobar.org moa
... then gethostbyname2() (and by extension, the hostname binary) returns
immediately with the DNS domain name, even with the machine unplugged
from the LAN. So it seems that gethostbyname2() does honor the host.conf
order, it was just falling back to trying to contact the LAN DNS server
when it couldn't find any valid IPv6 entries in /etc/hosts.
As '::1' is the IPv6 loopback address, I'm not sure that it's safe for me
to use it (it just works for gethostbyname2 because that ignores the
actual IP address portion, but there might be implications for other IPv6-
aware code) - but at least I seem to be getting to the bottom of *why*
the machine's behaving the way that it is.
I *think* I may be able to use the system's IPv4 address encoded in IPv6
format (::ffff:a.b.c.d/96), but I'm not certain yet :-)
|Re: slow hostname resolution / resolver behavior||Al||1/1/13 4:12 AM|
On 2012-12-31, Jules Richardson <jules.richa...@gmail.com> wrote:Are you running dnsmasq on the 13.1 machine and not on the 14.0?