Bind 8.2.2 P5 hanging up...

[Kevin Darcy]

Just because "Cleaned cache" is the last messages you see in the logs
before the failure doesn't necessarily mean that it's related to the
lock-up problem. Turn on debugging and that will give you a better idea
of what it was doing prior to the failure.

It does seem from the number of reports that there is some sort of
chronic problem with 8.2.2-p5 on Linux (what flavor/version of Linux, by
the way, you didn't specify?). If ISC isn't already actively on the
trail of this, then maybe some debugging output might help track down
the problem...


- Kevin

Philip L. Butler wrote:

> Hi,
>
> I am new to this list, so if this has been covered already I
> apologize.  I have scanned the list archives for help in this area -
> very useful information, but I am still puzzled a bit on a problem I
> am having.
>
> I am running a Linux box with Bind 8.2.2-P5.  Occasionally, it stops
> doing DNS for other machines.  From the logs, it seems (if I am
> interpreting them correctly) that it happens after the "Cleaned
> cache" message (see below) is logged and then subseqent DNS requests
> from the LAN result in the "Connection refused" message (see below).
> I have tried stripping all of my options out (listen-on and
> forwarders mainly) but that doesn't seem to help.  Rebooting helps
> for a while, but this obviously is not a permanent solution.
>
> I have scanned the OReilly DNS/Bind book (3rd edition) and there's an
> option to turn off clearing the cache, but it seems like I would want
> the Bind RAM cache to be pruned every so often.
>
> I haven't dug into the bind sources yet, but will be doing so soon.
>
> Has anyone run across this situation ??  In searching the bind-users
> archives for "ns_req", I see someone has had similar problems, but I
> haven't found the answer for my situation yet.
>
> Thanks in advance.
>
> Phil Butler
> butler at dii.net
>
> Logs
> ****
> Feb  3 15:48:08 (none) named[43]: Cleaned cache of 41 RRsets
> ...
> Feb  3 16:30:18 (none) named[43]: ns_req: sendto([172.23.9.2].137):
> Connection refused