Description of problem: There are no logs from named on my servers after rotation of logs. Is it possible, that Version-Release number of selected component (if applicable): bind-9.6.1-1.fc11.i586 bind-chroot-9.6.1-1.fc11.i586 but also fot F10 bind-9.5.1-2.P2.fc10.i386 bind-chroot-9.5.1-2.P2.fc10.i386 How reproducible: Steps to Reproduce: 1. yum install bind-chroot 2. echo "ROOTDIR=/var/named/chroot" >> /etc/sysconfig/named 3. service named start 4. rm -f /var/log/messages-`date +%Y%m%d` # remove todays rotated logs # also you need to remove all rotated files for today to make logrotate working 5. rm -f rm -f /var/lib/logrotate.status 6. logrotate --force /etc/logrotate.conf # do not use logrotate.d/named 7. service named reload 8. grep named /var/log/messages Actual results: nothing, empty output Expected results: at least something like this: Jun 24 10:35:42 localhost named[1721]: reloading zones succeeded Additional info: This does not help for me. What else need to be done for working chroot log rotation? touch /var/named/chroot/dev/log mount --bind /dev/log /var/named/chroot/dev/log
I'm not able to reproduce this issue. I used same steps as you wrote but after step 7 (service named reload) information that named was reloaded was written to the log. Could you please try to reproduce this issue without mounting /dev/log to chroot? It shouldn't be needed.
All rotated logfiles have to be removed before next logrotate (possible a logrotate bug?) Do this before logrotate: find /var/log -name \*-`date +%Y%m%d` -exec rm -f {} \;
After inspection this is a rsyslogd problem. New rsyslogd closes and reopens /dev/log when it gets -HUP (logrotate sends it). This behavior obviously breaks all applicantions which use chroot and syslog because there is no way how to get access to the new /dev/log file. [root@evileye x86_64]# stat /dev/log File: `/dev/log' Size: 0 Blocks: 0 IO Block: 4096 socket Device: dh/13d Inode: 46602 Links: 1 Access: (0666/srw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-06-24 16:02:53.775622723 +0200 Modify: 2009-06-24 16:02:53.775622723 +0200 Change: 2009-06-24 16:02:53.775622723 +0200 [root@evileye x86_64]# killall -HUP rsyslogd [root@evileye x86_64]# stat /dev/log File: `/dev/log' Size: 0 Blocks: 0 IO Block: 4096 socket Device: dh/13d Inode: 46622 Links: 1 Access: (0666/srw-rw-rw-) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-06-24 16:03:09.011613370 +0200 Modify: 2009-06-24 16:03:09.011613370 +0200 Change: 2009-06-24 16:03:09.011613370 +0200 I think there are two possible solutions for this problem: 1. Use functionality from rsyslog-3.21.11-HUPisRestart.patch and set "$HUPisRestart off" in the default rsyslog.conf 2. patch source to make sure /dev/log is opened only once Both approaches solve the problem. Reassigning to rsyslog for further inspection. Note that RHEL5 syslogd has "correct" behavior by default, it doesn't reopen the /dev/log.
Rsyslog indeed reopens the /dev/log socket, but this can't be easily prevented if you want to be able to restart the daemon. You can configure it to create an additional socket in the daemon's chroot with the $AddUnixListenSocket directive, though. See upstream doc [1] for more info. Reassigning back to bind. [1] http://www.rsyslog.com/doc-imuxsock.html
An solution for automatic chroot creation can be to include /etc/sysconfig/named configuration into rsyslog init script, then start initscript with environment set for named and update default rsyslog.conf with: if $environ contains "ROOTDIR" then $AddUnixListenSocket /var/named/chroot/dev/log There is no if $direxist()... or something similar in current rsyslog. But I think it's not best solution. :(
bind-9.6.1-5.P1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bind-9.6.1-5.P1.fc11
bind-9.6.1-5.P1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update bind'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9677
bind-9.6.1-6.P1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I'm seeing the same thing in EL5.5. I'm guessing that bug 516998 is the EL5 clone of this one, but I do not have permission to access it. Can something be done in EL5 to fix this? I'm not sure what the fix was to the F11 package or if it could be applied to bind-9.3.6-4.P1.el5_5.3.