logrotate(8) and copytruncate as default
P J P
pj.pandit at yahoo.co.in
Thu Jun 27 17:58:06 UTC 2013
----- Original Message -----
> From: Miloslav Trmač <mitr at 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
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).
More information about the devel