Keith Lofstrom <keithl@xxxxxxxxx> writes:
> Logrotate is the program called by cron to rename and expire log
> files. Ruedinger Oertel at SUSE (ro@xxxxxxx) has some patches that
> enhance the basic Redhat logrotate with "dateext". This allows a
> dated log file extension rather than a numbered one, for example
> /var/log/messages.20031029 . The old logfiles do not get renamed,
> just discarded after they get too old. This is a lot easier on
> rsync, and it also is easier to administer.
On Thursday, March 4 Harry Putnam responds:
> Note: These comments are not well researched... yet, but only a
> suggestion to pursue...
>
> I think they do get renamed... like:
> somelog becomes somelog.0
> somelog.0 becomes somelog.1
>
> Up to whatever number logrotate.conf is set to rotate `some.log'
> Seems like at each hop ... the file would have to be exactly the same
> size as its predecessor for this to effect rsync.
On Thursday, March 4 Keith Lofstrom clarifies:
Forgive me if I was unclear. I will explain in more detail. Indeed,
the current logrotate renames files; all the rotated log files get
renamed every day. rsync is not smart enough to notice that somelog.2
today was yesterday's somelog.1; it may be the same size, but it has
a different name and a different date. This is true for every numbered
extension. Rsync can't detect this, and will move a lot of files
because of it.
With the *optional* dateext method, the file somelog becomes
somelog.20040219 (one renaming when logrotate is run on 2004/02/20 ).
The next night, somelog becomes somelog.20040220, while somelog.20040219
is not changed in any way. If the logfile is configured to save 7 old
of somelog , then the file somelog.20040213 is discarded on the 20th.
Under the old numbering scheme, that same file would have been called
somelog.7 , and it would have changed names 7 times before the discard.
A backup program, a file security program like tripwire, and other programs
sensitive to changes in file names would have to be awfully smart and
awfully specific to know which of today's file names correspond to which
of yesterday's file names. So, *as an option* (not manditory!) the
dateext extensions permit log files to retain their extensions until they
are deleted. There is still one rename, from somelog to somelog.date,
but that could be fixed by a symlink, perhaps. As it is, reducing the
renamings from many down to one greatly simplifies a lot of problems.
Let me repeat, if I have not been clear before, this enhancement DOES
NOT CHANGE THE OLD BEHAVIOR. The old configuration files work exactly
the same, and cause the exact same behavior. The enhancement merely
permits *another* behavior, which is very useful for working modern
programs like rsync and tripwire, and it also permits the use of new
tools generated by the SUSE community, which has been using this exact
same enhancement for some time now on hundreds of thousands of machines.
Since logrotate does each logfile group from a separate configuration
section in logrotate.conf, it is quite feasible to number some groups
with numbers, and others with dates. This means that numbering can
remain for some groups to work with old logfile analyzers. However,
if the SUSE community comes along with a better analyzer, we can use
that, too. Why should they have all the fun?
I can patch my own system, with the patches that Ruediger Oertel of
SUSE keeps making on top of the Redhat/Fedora base. But this seems
an unnecessary waste of Ruediger's time; at some point his management
may say "to heck with Fedora compatability, just let the code fork"
and we will find our global community a little more fragmented and a
little less powerful.
But don't take my word for it; download the patch from SUSE and try
it. I am not sure what version of logrotate Fedora Core 2 Test is
up to, but if a new patch is needed Ruediger has always been a very
helpful and cooperative fellow, and he would probably invest the effort
to patch yet another new version of logrotate. I would not presume on
his helpfulness and generosity forever, though. Let's incorporate
his enhancements, so we can proceed together.
Keith
P.S. Again, here's that bugzilla page:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108775
--
Keith Lofstrom keithl@xxxxxxxx Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
