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