Bug 917560 - Rotated log file is still used for logging
Summary: Rotated log file is still used for logging
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ndjbdns
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: pjp
QA Contact: Fedora Extras Quality Assurance
URL: https://github.com/pjps/ndjbdns/
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-04 11:00 UTC by Simone Caronni
Modified: 2013-09-23 18:12 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-09-11 01:58:27 UTC


Attachments (Terms of Use)

Description Simone Caronni 2013-03-04 11:00:25 UTC
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


How reproducible:
Always.

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
  
Actual results:
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
# date
lun  4 mar 2013, 11.53.26, CET


Expected results:
The daemons should continue logging in the new log file without the date suffix after rotation.

Comment 1 pjp 2013-03-21 06:27:14 UTC
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 ??

Comment 2 pjp 2013-03-21 19:39:45 UTC
This is fixed now. No need to restart DNS servers. The logrotate(8) directive
`copytruncate' fits the bill. 

 -> https://github.com/pjps/ndjbdns/commit/be5fd0c90376b5c89e5b5dc3d57f64d905afe519

`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.

Comment 3 Simone Caronni 2013-03-22 08:52:38 UTC
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.

Many thanks!
--Simone

Comment 4 Simone Caronni 2013-03-25 14:40:03 UTC
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?

Thanks,
--Simone

Comment 5 pjp 2013-03-25 14:56:51 UTC
(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! :)

Comment 6 Fedora End Of Life 2013-04-03 20:41:31 UTC
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 7 Fedora Update System 2013-09-02 09:39:45 UTC
ndjbdns-1.05.8-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.8-1.fc18

Comment 8 Fedora Update System 2013-09-02 09:40:15 UTC
ndjbdns-1.05.8-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.8-1.fc19

Comment 9 Fedora Update System 2013-09-06 13:43:07 UTC
ndjbdns-1.05.8-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.8-1.el6

Comment 10 Fedora Update System 2013-09-06 13:44:01 UTC
ndjbdns-1.05.8-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/ndjbdns-1.05.8-1.el5

Comment 11 Fedora Update System 2013-09-11 01:58:27 UTC
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.

Comment 12 Fedora Update System 2013-09-11 01:58:53 UTC
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.

Comment 13 Fedora Update System 2013-09-23 18:11:25 UTC
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.

Comment 14 Fedora Update System 2013-09-23 18:12:23 UTC
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.


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