<tnvander@chello.nl> writes:
> > Van: James Antill <james@and.org>
> > > open("/etc/resolv.conf", O_RDONLY) = 3
> > > fstat(3, {st_mode=S_IFREG|0644, st_size=33, ...}) = 0
> > > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
> > > read(3, "search bogus\nnameserver 10.0.0.1"..., 4096) = 33
> > > read(3, "", 4096) = 0
> > > close(3) = 0
> >
> > This is a local nameserver then (Ie. you are running it on the same
> > machine ?). I'm guessing yes, so I'd look for the problem here first.
>
>
> This is indeed a local nameserver, and it does sometimes seem to fail. However, it's failure is very sporadic and even if it does fail, I'm wondering if it's really the failure of the local nameserver or the failure or my ISP's nameservers.
> I don't think that my problems are related to this local nameserver, as it's running on another machine which is not a Debian box (it works, and I never get round to converting it;). No configuration changes or software updates have been made to that box for a long time.
By local I meant on the machine that was having problems, Ie. on the
debian machine that you had put the devel version of glibc on.
From what you have said I guess it might be your ISP, as the calls to
the nameserver looked OK.
> That's one of my reasons for not seeking the reason there. Other reasons are that nameresolution-failures caused by the DNS server failing usually give different error messages, and that these specific error messages started occurring right after the upgrade to glibc-2.94 (and haven't yet disappeared with 2.95).
This could be better error reporting code in glibc 2.2, or maybe it's
reporting errors that used to make it retry.
> To make sure, I can test using another box when this happens again.
Might as well.
--
# James Antill -- james@and.org
:0:
* ^From: .*james@and.org
/dev/null