BIND "looses" interface while doing zone transfers

[Kevin Darcy]

I know there are problems running multithreaded on Solaris 2.6, but I thought
those only pertain to signal handling, which shouldn't be relevant here (AFAIK,
rndc doesn't use signals to control named). As a rough diagnostic step, do you
observe the same behavior when not using multithreading?


- Kevin

Kesper Kurt wrote:

> Hello,
>
> im using bind9.2.0rc3 (multithreaded, compiled with gcc) on Solaris 2.6.
> After inserting a 2nd CPU into the system bind stops answering requests
> coming via hme0 (fast ethernet) shortly after "rndc reload".
>
> The loopback interface remains active: nslookup-requests are answered and
> "rndc status" indicates no error. But another "rndc reload" fails. The
> command hangs and after that bind had to be killed and restarted because
> subsequent rndc-commands couldn't connect to bind.
>
> I observed also that the bind process was very busy for one or two minutes,
> just before it stopped answering on the network-interface.
>
> All this happened only when the serial number in the SOA of the zones was
> incremented. Without increment reloading bind worked as expected and without
> making bind so busy. So i concluded, that zone transfers could be the
> reason, and i tried with the option "transfers-out 1;" to reduce the traffic
> but without success.
>
> This effect occurs only with two CPUs. With only one CPU bind is also very
> busy after each reload and doesn't answer on hme0 for a minute or so (while
> still answering on lo0).
>
> Any ideas are greatly appreciated.
>
> Kurt Kesper