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