why doesn't rndc return exit status ?

Danny Thomas 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 mailing list