Hello Jan,
----- Original Message -----
From: Jan Kaluža <jkaluza(a)redhat.com>
Subject: Re: logrotate(8) and copytruncate as default
This is usually fixed by sending some signal to daemon in postscript
informing it that logs should be reopened. That way, no messages are
lost. The worst thing which can happen is that some messages get logged
in the rotated file for short time (after rename is done by logrotate
and before daemon reopens the new log).
Right, I did try that, but it does not help. Because 'ndjbdns' servers run
inside
a chroot(1) jail. At start-up these servers open the log file under - /var/log/ - and
change root directory to a secure location.
Now when logrotate(8) rotates the file, even if it signals to a DNS server that
it needs to start writing to a newly created file, server can't do it because -
/var/log -
is not visible/accessible from inside a chroot(1) jail.
If you use copytruncate, there is chance that some messages get lost
(as
stated in man logrotate). Making it default could surely make things
much easier and less error-prone, but I'm afraid we just can't remove
old behaviour completely right now and therefore it wouldn't save
anything regarding the problems you have mentioned.
I'm not sure if there would be much of data loss during copy-truncate.
Because that time window is tiny small. It is a similar race condition issue
as the current one, but much less severe. There's no chance of unprivileged
user access etc.
I also doubt if making copy-truncate default behaviour would break any
packages which depend on logrotate(8) to rotate their logs.
I'm not sure right now if the benefits of the
"copytruncate" usage
are strong enough in comparison with the possibility to lost the messages
during rotation.
I think we should try to evaluate for real how much data is lost, if any.
I will definitely try it and see how bad it is, but I presume for
bigger
logs it could be a problem.
That's cool! Please do let me know if I could help in any way.
Maybe it's just better to try to fix existing bugs and not
abandon the
"rename and reopen" way completely?
Well, existing bugs would be fixed anyway. I'm not saying we abandon rename
and reopen completely, may be we could provide it as an option in place of
'copytruncate'
say - 'createlog' or 'renamelog' or something like that.
Thanks so much!
---
Regards
-Prasad
http://feedmug.com