Date: Tue, 28 Sep 2004 02:55:58 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Juha Saarinen <juhasaarinen@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Proper way to run bind9 Message-ID: <20040928024928.R5094@ync.qbhto.arg> In-Reply-To: <b34be84204092719407a20d83f@mail.gmail.com> References: <1096042856.24267.6.camel@purgatory.ceribus.net> <xzpsm97v49e.fsf@dwp.des.no> <20040924222550.F6548@URF.trarfvf> <20040925001835.U7126@URF.trarfvf><20040927184543.I911@bo.vpnaa.bet> <b34be84204092719407a20d83f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Sep 2004, Juha Saarinen wrote:
> On Mon, 27 Sep 2004 18:54:01 -0700 (PDT), Doug Barton <dougb@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.
Thanks.
>> 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... :-)
*nod* Now that I've committed the chroot defaults, I may consider
changing this back to /var/run/named.pid .... I'll wait to see how the
chroot stuff falls out for people.
>> 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.
I think you missed the part of my previous message where I talked about
how the current system offers the maximum in terms of features and
flexibility.
> 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."
That same man page then defines the behavior for SIGINT and SIGTERM.
Killing named with a signal in this case is harmless, and should be
functionally equivalent to 'rndc stop', except in those cases where rndc
is buggered for some reason.
> Incidentally, shouldn't the 'rcvar" command print out all the options
> used in rc.conf for running named?
You might want to follow up with this question on
freebsd-rc@freebsd.org.
Hope this helps,
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040928024928.R5094>