This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 507795 - No logs in /var/log/messages after logrotate.
No logs in /var/log/messages after logrotate.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 516998
  Show dependency treegraph
 
Reported: 2009-06-24 06:21 EDT by Jan ONDREJ
Modified: 2013-04-30 19:43 EDT (History)
6 users (show)

See Also:
Fixed In Version: 9.6.1-6.P1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-24 01:14:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan ONDREJ 2009-06-24 06:21:47 EDT
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
Comment 1 Adam Tkac 2009-06-24 08:29:18 EDT
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.
Comment 2 Jan ONDREJ 2009-06-24 08:48:29 EDT
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 {} \;
Comment 3 Adam Tkac 2009-06-24 10:10:40 EDT
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.
Comment 4 Tomas Heinrich 2009-07-13 11:59:40 EDT
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
Comment 5 Jan ONDREJ 2009-07-17 02:18:09 EDT
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. :(
Comment 6 Fedora Update System 2009-09-16 07:53:26 EDT
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
Comment 7 Fedora Update System 2009-09-16 16:34:27 EDT
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
Comment 8 Fedora Update System 2009-09-24 01:13:59 EDT
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.
Comment 9 Orion Poplawski 2011-01-31 10:41:43 EST
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.

Note You need to log in before you can comment on or make changes to this bug.