----- Original Message ----- > On Thu, Jun 27, 2013 at 5:19 PM, P J P <pj.pandit@xxxxxxxxxxx> wrote: > > ----- Original Message ----- > >> From: Jan Kaluža <jkaluza@xxxxxxxxxx> > >> Subject: Re: logrotate(8) and copytruncate as default > >> 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). > > > > Right, I did try that, but it does not help. Because 'ndjbdns' servers > > run inside > > a chroot(1) jail. At start-up these servers open the log file under - > > /var/log/ - and > > change root directory to a secure location. > > > > Now when logrotate(8) rotates the file, even if it signals to a DNS server > > that > > it needs to start writing to a newly created file, server can't do it > > because - /var/log - > > is not visible/accessible from inside a chroot(1) jail. > > That's a possible argument for changing the ndjbdns logging/logrotate > configuration, AFAICS not an argument for changing the default. > > > >> 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 if there would be much of data loss during copy-truncate. > > > > Because that time window is tiny small. > > _Any_ data loss during normal operation is _unacceptable_. > > The rename+create new file+SIGHUP+reopen "protocol" is both safe and > widespread. > > "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 have the same opinion for now, but I will at least try to evaluate that locking idea. Maybe it can end up like more reliable copytruncate directive. > > 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. > Mirek > Jan Kaluza -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
