Even when the .jnl file is huge - I think that BIND writes out its
concept of the zone from its memory - as a freeze runs very quickly.
I guess the .jnl file is used to replay events to a "named" process that
is restarted??
Would be nice if named did a freeze/thaw cycle on being terminated???
--
. . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready
/| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
> An "rndc <domain> freeze" will consolidate the zone and remove the .jnl
> file, which should probably be followed rapidly with a "rndc <domain>
> thaw" command...
>
> Even when the .jnl file is huge - I think that BIND writes out its
> concept of the zone from its memory - as a freeze runs very quickly.
>
> I guess the .jnl file is used to replay events to a "named" process that
> is restarted??
>
> Would be nice if named did a freeze/thaw cycle on being terminated???
>
I added a couple of lines to my init.d script to do just that. Like this
stop() {
# clean up .jnl files
rndc freeze
rndc thaw
# Stop daemons.
But, since it adds the dynamic changes in force to my original zone file
(and increments the serial number), I found an oddly looking zone file.
Later updates removed the changes and restored the zone file but another
freeze incremented the serial number again.
I finally just left it alone as I was not concerned about the size of the
.jnl files as there is a set *max-journal-size 10K;* (under options).
So I removed that addition from the stop() routine.
David Forrest e-mail drf @ maplepark.com
Maple Park Development Corporation http://www.maplepark.com
St. Louis, Missouri
>An "rndc <domain> freeze" will consolidate the zone and remove the .jnl
>file, which should probably be followed rapidly with a "rndc <domain>
>thaw" command...
Yes. But this is not something you should ever need to do in normal
circumstances.
>Even when the .jnl file is huge - I think that BIND writes out its
>concept of the zone from its memory - as a freeze runs very quickly.
It does. It also does this from time to time (c. 15 minues after an
update) during normal running. This does not mean that it clears the
journal file.
To stop the journal file getting out of control, you can use the
"max-journal-size" setting in "options" or "zone" statements.
>I guess the .jnl file is used to replay events to a "named" process that
>is restarted??
The journal file is used not only for replaying updates not yet
committed in the zone file, but also to provide the data for
incremental zone transfers (IXFR).
>Would be nice if named did a freeze/thaw cycle on being terminated???
"rndc stop" (as opposed to "rndc halt") does commit transactions to
the zone file(s). But it doesn't clear the journal files, and nor
should it.
--
Chris Thompson
Email: ce...@cam.ac.uk
An "rndc <domain> freeze" will consolidate the zone and remove the .jnl
file, which should probably be followed rapidly with a "rndc <domain>
thaw" command...
Even when the .jnl file is huge - I think that BIND writes out its
concept of the zone from its memory - as a freeze runs very quickly.
I guess the .jnl file is used to replay events to a "named" process that
is restarted??
Would be nice if named did a freeze/thaw cycle on being terminated???
On Tue, 2008-10-07 at 17:00 +0800, Li Tongxi wrote:
This is with respect to a zone used for dynamic updates - and where the
slave is on the same network... so there are no outstanding IXFR's -
which might otherwise keep the .jnl file around.
I guess thats my specuation, observed from (limited?) real(-ish) world
experience and I should have said "may consolidate" rather than "will
consolidate".
After running nsupdate, I executed the following command to update the
master zone file(s) and remove the journal file(s).
rndc freeze zone
I then used the following command to make the zone available.
rndc thaw zone
The name server being used was running BIND 9.3.5-P2.
Merton Campbell Crockett
Merton Campbell Crockett
m.c.cr...@roadrunner.com