'succesful' nsupdate of remote server not persistent across nameserver restart?
p.mayers at imperial.ac.uk
Sun May 1 18:30:42 UTC 2016
On 01/05/16 19:05, Phil Mayers wrote:
> On 30/04/16 04:49, jasonsu at mail-central.com wrote:
>> On Fri, Apr 29, 2016, at 08:42 PM, Mark Andrews wrote:
>>> Just give it time. The zone contents are the masterfile + journal.
>>> The masterfile only gets written periodically as it can be a expensive
>> Sure, under normal operation, as I understand it.
>> IIUC, though, a nameserver restart is supposed to force the
>> write-to-journal immediately, right?
> No, I don't think so.
Doh, never mind. As has been pointed out elsewhere in this thread, it
depends how named is stopped (rndc stop vs. halt, kill -XYZ and which
If it's being stopped in an appropriate way to write the zone file, and
it's not writing the zone file, then there really aren't many options -
permissions, SELinux/AppArmour, or something similar.
If it's not being stopped in a way that'll write the zone file, change that.
Standard tricks like strace'ing the named process as you shutdown the
daemon may help (strace -f -o -strace.txt p $NAMED_PID). I'm assuming
there's nothing in the bind or system logs indicating an error.
TBH I'd drop the chroot - you're just complicating something that you're
already having trouble with. Try it without a chroot and see if it
behaves as you expect.
More information about the bind-users