Hello Miloslav, ----- Original Message ----- > From: Miloslav Trmač <mitr@xxxxxxxx> > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
