logrotate(8) and copytruncate as default

[Jan Kaluža]

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