On Jan 9, 2009, at 9:38 AM, Chris Buxton wrote:
On Jan 9, 2009, at 3:14 AM, Scott Haneda wrote:
It is getting important to know if you are on Mac OS X, if you are,
this may have been solved, and somehow, I overlooked it.
It appears launcd, the cron replacement tool in OS X, can start
named before the network interfaces come up. I am not sure.
When this problem occurs, it affects all of named's ports, not just
the TCP port. Also, Apple's version of BIND is not built from the
stock source code; they have modified it to request that the kernel
send a SIGHUP whenever the network configuration changes, to work
around this very problem.
Unfortunately, their solution requires that named run as root. The
wrapper script you posted was written as a different way to solve
the same issue, and it does not rely on named running as root. It
just waits for a network interface other than the loopback interface
to be configured before starting named.
We have seen named's TCP port go deaf over time on Mac OS X, without
any reboot in between. We have not been able to find a reason, but
it may be that if the port is inactive for a long period of time,
something may close or block it.
Thanks Chris. If that is the case, then the wrapper script is not
going to help me. I think my first course of action is going to be to
update named and move it elsewhere so Apple does not write over it.
After that, what do you think about a small tickler that pokes into
port 53 every now and again to prove if silence time is really causing
it to close?
I am thinking that window of silence must be pretty small, since zone
transfers happen pretty regularly on my machine. As a matter of fact,
I have been adding more domains to my system in the last few months
than I ever have before. With that, my secondary has been requested
to pull them down more than I have before as well.
Thanks for your input.
--
Scott
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users