Red Hat Bugzilla – Bug 131553
chrooted binds fail named-checkconf in initscript
Last modified: 2007-11-30 17:07:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
The initscript from the latest update does not pass the ROOTDIR or
OPTIONS variables to the named-checkconf call, nor the call to named
when checkconf fails, so if the daemon is chrooted then the daemon is
not restarted after an upgrade with errors such as:
Sep 02 17:53:58.951 starting BIND 9.2.4rc6 -g
Sep 02 17:53:58.951 using 4 CPUs
Sep 02 17:53:58.955 loading configuration from '/etc/named.conf'
Sep 02 17:53:58.956 none:0: open: /etc/named.conf: permission denied
Sep 02 17:53:58.956 loading configuration: permission denied
Sep 02 17:53:58.956 exiting (due to fatal error)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. have ROOTDIR set in /etc/sysconfig/named
2. upgrade bind to latest version in RHEL 3ES update 3, by up2date
3. manually try to restart bind and observe error above
Actual Results: up2date process starts timing out, diagnosis suggests
DNS timeouts, observation shows named process not running anymore.
manual restarts fail, with above error
Expected Results: bind should have been ugpraded and restarted as no
configuration changes were made.
I fixed this locally by adding $OPTIONS to the end of the
named-checkconf call on line 41, and again to named -g on line 47 of
Though not technically a "crash", caused unexpected outage on
nameserver, hence severity High.
Yes, this bug was found earlier in bug #130981 and fixed in
bind-9.2.4rc7-10 - the next version for RHEL-3 will contain
*** This bug has been marked as a duplicate of 130981 ***
It has been reported as bug #131553 and closed as fix in FC Devel tree.
Sorry. Wrong place for commnet. Should be for bug #131803.
This is fixed in RHEL-3 with bind-9.2.4-1_EL3
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.