Red Hat Bugzilla – Bug 19275
allow strftime() expansions of "extension" directive?
Last modified: 2007-04-18 12:29:23 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.
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
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
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...
Rather, it you did #2 only (#1 doesn't need to be implemented at all if #2 is in
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).
Do you have this patch available?
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.
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
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.