Hello Miloslav,
----- Original Message -----
From: Miloslav Trmač <mitr(a)volny.cz>
Subject: Re: logrotate(8) and copytruncate as default
That's a possible argument for changing the ndjbdns logging/logrotate
configuration, AFAICS not an argument for changing the default.
Yes, 'ndjbdns' has already fixed this issue by using 'copytruncate'.
Change was not suggested only for ndjbdns, but together with another
race condition and in anticipation of other such issues which we aren't aware
of. Default copy-truncate appears to address all those. IMHO, renaming a
file which is being written to by another application does no feel right.
_Any_ data loss during normal operation is _unacceptable_.
Sure! As per the experiment so far, there is no data loss at all.
The rename+create new file+SIGHUP+reopen "protocol" is both
safe and
widespread.
Safe? There is a race condition in it for which a CVE has been assigned.
And if anything, its widespread usage only increases the concern.
"copytruncate" is not at all an alternative on equal
footing because
it can, and sooner or later _will_, loose data. We could invent some
kind of "suspend logging signal"+copytruncate+"resume logging
signal" protocol I suppose, but that puts the burden of suspending logging on
the application, and still has a larger risk of data loss (if the
application crashes after trying to log a message).
I think we are yet to know for sure if there would be any data loss.
If the way ndjbdns logs is inherently prone to losing data,
that's a
fairly severe bug that needs fixing. Using "copytruncate" in the
ndjbdns configuration is at best an incomplete workaround.
ndjbdns logging is not prone to losing data. And It already uses
copytruncate to continue writing to a proper file after logs have been
rotated by logrotate(8).
---
Regards
-Prasad
http://feedmug.com