From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 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): bind-9.2.4-EL3_10 How reproducible: Always 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. Additional info: 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 /etc/init.d/named 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 the fix. *** 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.