On 06/27/2013 01:54 PM, P J P wrote:
Hi,
Recently I've seen multiple issues related to new file creation by logrotate(8).
A race condition described by [1], between creation of a new file and setting
file permissions and acl(5). Another I came across in ndjbdns [2], as it continued
to write to an open, but rotated log file.
Hi,
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).
Wouldn't it be better to make 'copytruncate' as default behaviour for logrotate(8)?
Instead of renaming an old file and creating a new one.
[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1098
[2] https://github.com/pjps/ndjbdns/commit/be5fd0c90376b5c89e5b5dc3d57f64d905afe519
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 right now if the benefits of the "copytruncate" usage are
strong enough in comparison with the possibility to lost the messages
during rotation.
I will definitely try it and see how bad it is, but I presume for bigger
logs it could be a problem.
Maybe it's just better to try to fix existing bugs and not abandon the
"rename and reopen" way completely?
Thank you.
---
Regards
-Prasad
http://feedmug.com
Regards,
Jan Kaluza
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
