logrotate(8) and copytruncate as default

[Jan Kaluza]

----- Original Message -----
>    Hello Jan,
> 
> ----- Original Message -----
> > From: Jan Kaluža <jkaluza at redhat.com>
> > Subject: Re: logrotate(8) and copytruncate as default
> > 
> > I'm not sure right now if the benefits of the "copytruncate" usage are
> > strong enough in comparison with the possibility to lost the messages
> > during rotation.
> 
>    I did a small experiment to test how much data loss would incur in
>    copy-truncate.
> First command constantly writes to a file. While the second one uses an
> exclusive lock to temporarily halt the write operation, do a copy, truncate
> and
> release the exclusive lock so that the write continues where it was stopped.
> 
> 
> ===
> $ cd /tmp/exp/
> 
> # Following command continuously writes to a file.
> #
> 
> $ (count=0; while(true); do count=`expr $count + 1`;  \
>     echo `date "+%d %a %Y %T"` $count; done >> test.log &)
> 
> # Following command uses exclusive lock to halt the write
> 
> # operation, perform copy-truncate, and release the lock.
> #

Hm, logrotate doesn't do the locking right now. I will have to
read the ma pages to find out how that works exactly and if there 
aren't some problems with that. Maybe you are right and we could
fix the lost messages with locking. It's worth a try. I'm only
sceptical about possible breakage of some daemons if we start
locking their logs. It's definitely big change in current behaviour.

Right now, without locking, logrotate would loss more messages if the
logs are big, because copying takes more time. It would be interesting
to mention the file size in your tests too. But as I said, if the
exclusive lock pauses the writing operations to the lock file, you
won't be able to reproduce it with your current reproducer.

> $ flock -x test.log -c 'cp test.log test.log.1; > test.log'
>
> $
> 
> $
> 
> $ tail -n -4 test.log.1
> 27 Thu 2013 21:14:14 7317
> 27 Thu 2013 21:14:14 7318
> 27 Thu 2013 21:14:14 7319
> 27 Thu 2013 21:14:14 7320
> $ head -n 4 test.log
> 27 Thu 2013 21:14:14 7321
> 27 Thu 2013 21:14:14 7322
> 27 Thu 2013 21:14:14 7323
> 27 Thu 2013 21:14:14 7324
> 
> ===
> 
> 
> As can be seen above, there does not seem to be any data loss at all.
> 
> 
> Thank you.
> 
> ---
> Regards
>    -Prasad
> http://feedmug.com
> 

Regards,
Jan Kaluza