logrotate(8) and copytruncate as default

[Jan Kaluza]

----- Original Message -----
> On Thu, Jun 27, 2013 at 5:19 PM, P J P <pj.pandit at yahoo.co.in> wrote:
> > ----- Original Message -----
> >> From: Jan Kaluža <jkaluza at redhat.com>
> >> 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