Proper way to run bind9

Doug Barton DougB at
Mon Sep 27 18:54:07 PDT 2004

On Tue, 28 Sep 2004, Juha Saarinen wrote:

> The PID file location for currently hardcoded to /var/run in the named binary.

You are correct.

> Is there a good reason for not changing that to /var/run/named/pid as
> the default on FreeBSD, instead of adjusting the location in both
> /etc/defaults/rc.conf and named.conf?

A couple of them actually. We do not want to edit the files as they come 
from the vendor without a really good reason, and this isn't one.

I have a long term plan to write some patches to turn the pid file path 
into a --configure defineable variable and send it to the ISC folks, but 
it's frankly not that high a priority.

> This is error-prone, and easy to forget -- if you do, it means named 
> won't start up as it cannot write the PID file to the default 
> location.

If you use the system as installed, and/or start from the default files, 
it's all there for you. If you choose to vary from that path, it's 
pretty much up to you to know what you're doing and why. There are only 
so many bullets you can take out of the foot-shooting gun.

That said, I did add a comment to the src/etc/default/rc.conf file which 
indicates that if you change the pid file name there, you should change 
it in named.conf as well to make it easier for users to do the right 

Finally, the way named fails in this case (totally) is actually the 
safest way to handle it. No user can accidentally start named with the 
wrong configuration and have it running in a manner other than what they 
expect. This is a much more serious problem, and would be worthy of a 
better solutino if it existed. The problem you describe here is a 
learning curve issue, and BIND has a lot of those.

> Second, shouldn't /etc/rc.d/named be rewritten to take rndc into
> account, and not use /etc/rc.subr?

What would your goal be? With the current behavior, '/etc/rc.d/named 
stop' can recover from situations where 'rndc stop' fails. Why would you 
want to take that functionality away?



     This .signature sanitized for your protection

More information about the freebsd-current mailing list