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).
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
