Red Hat Bugzilla – Bug 917560
Rotated log file is still used for logging
Last modified: 2013-09-23 14:12:23 EDT
Description of problem:
The daemons are not sent the correct signal when rotating the log files.
Version-Release number of selected component (if applicable): ndjbdns-1.05.6-1.fc19
Steps to Reproduce:
1. Start any daemon with DEBUG enabled
2. Generate some traffic
3. See the logs rotate and the main log file be empty
As you can see from the output below the daemon keeps on logging into the rotated file and does not log in the main one:
# ls -alghs tinydns.log*
0 -rw-r--r--. 1 root 0 3 mar 03:08 tinydns.log
4,0K -rw-r--r--. 1 root 285 18 feb 09:11 tinydns.log-20130203
8,0K -rw-r--r--. 1 root 4,9K 19 feb 14:16 tinydns.log-20130219
20K -rw-r--r--. 1 root 18K 26 feb 11:25 tinydns.log-20130224
52M -rw-r--r--. 1 root 52M 4 mar 11:53 tinydns.log-20130303
lun 4 mar 2013, 11.53.26, CET
The daemons should continue logging in the new log file without the date suffix after rotation.
I looked into this issue. It seems more complex than I thought.
When logrotate(8) rotates a file, it renames it, leaving the open file
descriptors unaffected. This causes servers to continue logging to a rotated file.
A straight forward solution would be to just hint the server that the log file
has been renamed, please create new one and continue logging there.
It becomes complex because DJBDNS servers run inside a chroot(1) jail located
at the $ROOT directory. Here, servers acquire privileges of the `daemon' user.
Once inside the chroot(1) jail as daemon, servers can not create log file
under `/var/log/' directory. One because it has no privileges and second
because `/var/log' does not exist inside chroot(1) jail.
This brings us to a slightly tacky solution:
- Is it possible to restart a server after logrotate(8) ?
- If so, what is the extent of the damage incurred ??
This is fixed now. No need to restart DNS servers. The logrotate(8) directive
`copytruncate' fits the bill.
`copytruncate' directive copies content of the original log file to a new one, and leaves the old file as is.
Patch needs review and testing though.
Sorry for being late, I've been pretty busy. Put the patch into place now, the log does not need rotation yet, I'll update info here in the next days.
Confirmed, it works properly!
Is it ok for you to issue ndjbdns-1.05.7-2 with the patch or you want to wait for ndjbdns-1.05.8?
(In reply to comment #4)
> Is it ok for you to issue ndjbdns-1.05.7-2 with the patch or you want to
> wait for ndjbdns-1.05.8?
I think let's wait for 1.05.8? I hope it'll be soon.
Thanks so much for confirming! :)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
ndjbdns-1.05.8-1.fc18 has been submitted as an update for Fedora 18.
ndjbdns-1.05.8-1.fc19 has been submitted as an update for Fedora 19.
ndjbdns-1.05.8-1.el6 has been submitted as an update for Fedora EPEL 6.
ndjbdns-1.05.8-1.el5 has been submitted as an update for Fedora EPEL 5.
ndjbdns-1.05.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ndjbdns-1.05.8-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
ndjbdns-1.05.8-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
ndjbdns-1.05.8-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.