logrotate(8) and copytruncate as default

[Miloslav Trmač]

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).


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