Proper way to run bind9
Juha Saarinen
juhasaarinen at gmail.com
Mon Sep 27 19:40:15 PDT 2004
On Mon, 27 Sep 2004 18:54:01 -0700 (PDT), Doug Barton <dougb at freebsd.org> wrote:
> 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.
Humm, that does seem like the right way to do it, instead of working
around the issue by changing the PID file location in two different
places.
> 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.
True -- however, this is likely to bite people who migrate from other
platforms where you don't have to specify the PID file location in
named.conf, unless you want it in a non-default location. But, people
have plenty of toes I suppose... :-)
> 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?
Well, rndc is the vendor-supplied tool for controlling the operation of named.
The man page for named(8) says:
"In routine operation, signals should not be used to control the name-
server; rndc should be used instead."
Correct me if I'm wrong, but doesn't /etc/rc.subr use signals?
Incidentally, shouldn't the 'rcvar" command print out all the options
used in rc.conf for running named?
$ sudo /etc/rc.d/named rcvar
# named
$named_enable=YES
/etc/rc.conf
named_enable="YES" # Run named, the DNS server (or NO).
named_program="/usr/sbin/named" # path to named, if you want a different one.
named_flags="-c /etc/namedb/named.conf -u bind" # Flags for named
--
Juha
More information about the freebsd-current
mailing list