From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: I added the following lines to named.conf: logging { channel default_syslog { syslog local2; severity info; }; category lame-servers {null;}; // don't log these ... category queries {default_syslog;}; category config {default_syslog;}; category security {default_syslog;}; }; After restarting the service, Bind logs to syslog just fine. However, after rebooting the machine, Bind does not log to syslog anymore. Version-Release number of selected component (if applicable): bind-9.3.1-10_FC4 How reproducible: Always Steps to Reproduce: 1.Configure named.conf as indicated above to enable syslog logging 2.Reboot system 3. Actual Results: named does not log to syslog after reboot Expected Results: named should log to syslog after reboot Additional info: It turns out, the cause is that named is placed before syslogd in the boot sequence: # ls /etc/rc3.d/ | egrep -e "S??named" -e "S??syslog" S11named S12syslog I modified /etc/init.d/named to launch named after syslog: # diff -u named named.orig --- named 2005-08-29 14:37:17.000000000 -0700 +++ named.orig 2005-08-29 14:37:06.000000000 -0700 @@ -3,7 +3,7 @@ # named This shell script takes care of starting and stopping # named (BIND DNS server). # -# chkconfig: - 13 87 +# chkconfig: - 11 89 # description: named (BIND) is a Domain Name Server (DNS) \ # that is used to resolve host names to IP addresses. # probe: true Then I did a "chkconfig --del named; chkconfig named on" and now named logs to syslog just fine after a reboot. P.S.: The syslog lines in named.conf were copied verbatim from here (two typos on that webpage in the "category" lines were silently corrected): http://www.hansenonline.net/Networking/bind.html
*** Bug 167064 has been marked as a duplicate of this bug. ***
The default start order for syslogd and named is reasonable, but may need to be customized to suit specific needs as you have done. Both syslogd and named should be started before "13" in runlevel 2 if a local named resolver is being used, as the RPC "portmap" daemon also has order 13, and the boot process will hang for a long time if a local nameserver and NIS is being used and portmap is started before named. I run syslog with '# chkconfig: 2345 0 99' with no problems. But then I do not use network logging, where syslog is told to log all its messages to a remote host, and where it must perform a successful host name lookup in order to do so, nor do I have a '.' in the hostname. If the "hostname" of the local host has a '.' in it, or network logging is being used, syslogd will attempt to perform a host name lookup for the hostname on startup, and if the hostname is not in /etc/hosts, this by default will timeout for a long time (@ 5mins) if a local resolver is being used and syslogd is started before named . Thus syslog can depend on named if the machine is configured to use a local named resolver, and will hang for a long time on startup if network logging or a hostname containing '.' and a local resolver are configured and named is started after syslogd. Also, the /etc/rc.d/init.d/syslog file is installed as a "%config(noreplace)" file, so it cannot be replaced and the search order cannot be changed by an RPM upgrade. Users typically do change the startup order of daemons to suit individual requirements, and these changes should not be wiped out by an RPM upgrade. In this case, the default start order is reasonable, but cannot be suitable for EVERY possible configuration of named and syslogd; users have to customize the configuration to suit their requirements. However, I agree that named should by default be started after syslogd. I have now changed the default startup order of BIND in Rawhide to be: '# chkconfig: - 13 87 ' and this will take effect after a BIND upgrade - this will be in BIND 9.3.1-12+ (rawhide) and BIND 9.3.1-11_FC4+ (FC-4) - this will go in within the next few weeks. So by default, named will be started after syslogd and this problem will not occur; this means users of network logging or with hostnames containing '.' who use named as a local resolver will have to change the startup order, or not use syslogd for named logging.