httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From glim <g...@employease.com>
Subject rotatelogs improvement
Date Fri, 05 Dec 2008 18:34:44 GMT
Greetings. If this isn't being sent to the correct list, I apologize. 
Let me know and I'll go elsewhere.

I'd like to make a minor improvement to rotatelogs and wanted to check 
with the list to see what would be most appreciated.

"rotatelogs" as it stands now cannot rotate by time and date in a single 
invocation.

I'm willing to write a patch to do this, but as I said, I'd like to find 
out what would best suit the community.

The problem: For log analysis, we'd like the day-of-the-year to be 
contained in the name of the logfile. IOW any given logfile should only 
contain logs for events happening during that day. We would also at the 
same time, like to insure that logs do not grow larger than 500M. 
Rotatelogs accepts a single parameter to specify a condition for 
rotation. You can select size XOR time-based rotation - not both. You 
can see why from the current syntax:
rotatelogs [-l] [-f] <logfile> {<rotation time in seconds>|<rotation 
size in megabytes>} [offset minutes from UTC]

I'd propose something more like this:
%s [-l] [-f] [-s=rotation-size-in-megabytes] 
[-t=rotation-time-in-seconds [-o=offset-minutes-from-UTC]] <logfile>

Here are some options:

1. new syntax - pro: upgrade all options to use apr_getopt(), simple 
syntax, relatively small patch to rotatelogs. con: requiring flags for 
options will break unprepared users.

2. syntax change and retain old syntax as well - pro: everything stays 
working for users of old and new syntax, but con: the code for 
rotatelogs becomes relatively messy. I really don't like this option.

3. distribute 2 versions of rotatelogs - pro: it keeps the new code 
simple(and still mostly matching the old rotate logs). old rotatelogs 
stays exactly the same except for maybe a note that the old syntax might 
be deprecated. con: there are pointlessly 2 versions of rotatelogs. A 
future (major) release of apache could just remove the older rotatelogs 
and be done with it.

What would be most acceptable?
1. I don't like randomly breaking setups just because options have to change
2. I don't like overcomplicating code. Someone would have to remember to 
pull out the legacy options stuff.
3. It seems foolish to have 2 versions of rotatelogs.


-Greg Lim

Mime
View raw message