why doesn't rndc return exit status ?
d.thomas at its.uq.edu.au
Sat May 24 00:20:50 UTC 2008
unlike many daemons, bind allows for configuration changes without
restarting, since doing so can be slow and lose cache contents. That's
good, but it seems the exit status of rndc does not reflect the
success/failure of the operation. The manpage makes no mention of the
return status so this seems like a concious decision.
after adding syntax error to named.conf
# rndc reconfig
# echo $?
general: info: received control channel command 'reconfig'
general: info: loading configuration from '/opt/named/named.conf'
config: error: /opt/named/named.conf:7: unknown option 'x'
general: error: reloading configuration failed: failure
I've got a cron job on each of our secondaries rsyncing it's config
which is prepared on a central system. It does an "rndc reconfig" when
the config changes, but I want to detect if there's a problem and roll-
back to a copy of the last config successfully loaded. Maybe I should
settle for just syntax-checking with named-checkconf, but it seems a
bit lame that the management tool isn't helpful. A hack approach would
be to use a timestamp with server-id in the config and use a dns query
to verify the new config has been successfully loaded.
FWIW this is 9.5.0rc1 but previous testing was with 9.4.2
speaking of init scripts we recently had a problem with dhcpd not
starting after a reboot. Turns out the old pidfile listed a pid now
belonging to a process (/sbin/mingetty as it turns out). Problem is
the parent dhcpd process immediately returns a 0 on successfully
forking, while the daemon process immediately performs this check and
does an exit(1).
More information about the bind-users