Bug 19275 - allow strftime() expansions of "extension" directive?
allow strftime() expansions of "extension" directive?
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
7.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-17 13:28 EDT by James Ralston
Modified: 2007-04-18 12:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-26 16:48:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2000-10-17 13:28:50 EDT
On most systems I administer, I have patched the log rotation program(s)
such that the extension used for the log files that have been rotated is
the date on which they were rotated.

For example:

    syslog.mail
    syslog.mail.2000-10-14.gz
    syslog.mail.2000-10-15.gz
    syslog.mail.2000-10-16.gz
    syslog.mail.2000-10-17.gz

I started using this scheme in attempt to better organize the logs on my
production systems for easy searching capabilities.  I rely upon it now,
and I won't go back.  :p

Currently, logrotate is not powerful enough to do this, but I'm peering at
the source now, the enhancements that would be necessary don't seem too
difficult.  The "extension" directive could be expanded using strftime(),
possibly controlled by "[no]interpret" directives.  Using a non-fixed
extension would break logrotate's current ability to keep track of how many
old versions of a particular log file are lying around, though.  You'd need
another directive pair like "[no]serialnumber", which would would toggle
between these two behaviors:

    1.  Logrotate always appends a serial number (1, 2, 3, ...) to the
        old logfile, and renames old logfiles so that logfiles with a
        higher serial number are always less recent.  Logrotate uses
        the serial number both to determine how many old log files are
        around, and to order the old log files from most recent to
        least recent.

    2.  Logrotate does not append a serial number or rename old
        logfiles created by previous logrotate runs.  Instead,
        logrotate assumes that a file whose name begins with the
        current logfile name plus "." is an old log file created by a
        previous logrotate run.  Logrotate uses the stat() mtime value
        to order the old log files from most recent to least recent.

In order to make any sense, "serialnumber" would have to imply
"nointerpret", and "noserialnumber" would have to imply "interpret".

Ok, now here are the important questions: if I were to submit a patch for
logrotate back to you that would implement the above behavior, would you
accept it?  Why or why not?  Do you have any suggestions on the above
scheme?  (E.g., "If you did [x] and [y] instead of [a] and [b], I'd accept
the patch.")
Comment 1 Erik Troan 2000-10-23 10:45:54 EDT
If you did only (b), I'd accept the patch. Please make sure you're using the
latest logrotate source, and test it well though...
Comment 2 Erik Troan 2000-10-23 10:47:13 EDT
Rather, it you did #2 only (#1 doesn't need to be implemented at all if #2 is in
place).

You need to be careful in the glob, but it's definitely doable. In particular,
if one log entry is for my.file and the another is for my, make sure you don't
confuse the two (as my.* matches my.file).
Comment 3 Preston Brown 2001-06-21 15:36:03 EDT
Do you have this patch available?
Comment 4 James Ralston 2001-06-26 16:48:24 EDT
Thanks for the reminder--I had meant to get back to this.

I set out to work on the patch, but I got stuck on the glob issues.  After
further thought, I don't think having logrotate assume "any file that begins
with the current logfile name plus "." is an old log file" is a good idea, as
that may grab logfiles that are being manually manipulated for some reason. 
(E.g., if you do "cp named.1 named.problems", in order to examine that
particular logfile later, logrotate could come along and purge named.problems
from underneath you.)

The only solution I've come up with is this: if logrotate is instructed to
expand the extension directive via strftime(), logrotate never tries to find and
remove old logfiles; rather, it assumes that someone will either be removing old
logfiles manually, or that someone will set up a crontab entry like:

    find /var/log/OLD -type f | xargs -er rm

I'm not particularly thrilled with this solution, but I think I like it better
than trying to glob in such a way as to never glob the wrong file.  I don't
think that's possible 100% of the time.

Of course, I dislike creating a situation where a sysadmin could wind up
creating an infinite number of logfiles and wind up filling up his disk, but I
think clearly documenting a "strftime() interpretation disables purging of old
logfiles" feature (and not shipping it as a default!) would mostly prevent that.

Thoughts?
Comment 5 Preston Brown 2001-07-02 14:04:07 EDT
Some of your thoughts were the same as mine.  I think that if you are interested in 
getting date extensions on your logs as they are rotated, you could write a script (run 
from cron) that renamed logrotate.? by replacing the number signified by ? with the 
timestamp of the file, which should be the time it was rotated.  Not having a reliable way 
to remove logs is going to be problematic and defeat one of the main purposes of 
logrotate.

Since the information on log rotation time is preserved via the filesystem, I'm going to 
have to close this report now and leave it up to system administrators to decide how 
best to use that information.

Note You need to log in before you can comment on or make changes to this bug.