Open Radar

 
Summary:
I recently added a new domain to the named.conf file and HUPped it.  When I added the domain to my slave server, I discovered that it couldn't connect to the OS X box to transfer the domain record.

After spending half a hour HUPping named on my OS X master and my Linux slave box, trying dozens of different config tweaks to try to figure out why my zone transfers stopped working, I stumbled across this thread from 2009:

    https://lists.isc.org/pipermail/bind-users/2009-June/076939.html

Apparently, named on OS X occasionally stops listening for incoming connections on port 53, and does not start listening unless you kill and restart the named process.

I tried doing a "kill -TERM" on the named process, and it stopped listening immediately, but the process never exited, so after almost a minute, I resorted to doing a "kill -9".  Half a second later, launchd restarted it, and the new named process was listening on port 53 as expected.

I wish I had thought to run sample on the process so that I could tell you where the process was wedged, but I didn't.  If I see it again, I will.  In any case, I wanted to make sure you were aware of the bug.  I suspect that if you write a script that repeatedly adds new domains and HUPs named over and over (maybe without even adding domains), you'll eventually be able to reproduce the wedge/failure to re-bind to non-loopback interfaces.  I'm guessing it's a race condition somewhere in the reinitialization code.

Steps to Reproduce:


Expected Results:


Actual Results:


Version:
3.1.1

Notes:


Configuration:
OS X v10.9.2

Attachments: