The current implementation of log rolling is too
restricted in my opinion. Logging every so many days is
standard for larger sites, but smaller sites, like the
few I run, would benefit from rolling on a date
schedule, like monthly or bimonthly. This makes log
analyses simpler and keeps fewer files.
I have checked the source code and found that you store
the time of the last roll and you keep checking whether
the specified number of days passed. I think that
reversing the logic would allow the desired flexibility:
to store the time of the next roll and keep checking
whether it passed. The rolling routine would be
responsible for calculating the time of next roll and
updating the global after it successfully finished the
current roll. The time of last roll should be saved in
the prefs file for permanency thru startups.
The only thing that needs to be added is a parser that
runs upon loading, converts the .config parameters into
globals that can be used by the roll routine to compute
the next roll time, and does the calculation of the next
roll (using saved last roll time). It should also force
a log roll if appropriate.
The config file would then allow
LOG_ROLLOVER DAYS 7
LOG_ROLLOVER MONTHLY
LOG_ROLLOVER SUNDAY
I would also add optional (default to 1 min after
midnight):
LOG_ROLLOVER_TIME 01:05
Logged In: YES
user_id=475612
Another option for log rolling, perhaps in addition to the
"fixed time" option, would be to roll based on log size.
This, in conjuntion with AppleEvent notification of same,
would allow invocation of a "compressor" (e.g., StuffIt)
and AppleScript to do "n" generations.
(comment added by "pasekma")