<[EMAIL PROTECTED]> writes:
> > Van: James Antill <[EMAIL PROTECTED]>
> > > 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 -- [EMAIL PROTECTED]
:0:
* ^From: [EMAIL PROTECTED]
/dev/null
