Re: rotatelogs improvement
On 05.12.2008 22:41, Paul Querna wrote: glim wrote: 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. ... 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. I'd vote for doing this on trunk, 2.2.x backport can be skipped or rethought once we have it working. I just found these mails. I committed a change to trunk a few days ago, that allows rotation based on time *and* size. Since I wasn't sure about the configuration portability goals for 2.4, I chose to not introduce an incompatible syntax. So with trunk rotatelogs you can have: A) rotationtime|filesizeX [ offset ] or B) rotationtime filesizeX [ offset ] C) filesizeX rotationtime offset What will not work is: filesizeX rotationtime (would be interpreted as A with offset, the price we pay for compatibility). X above has to be exactly one of the characters B,K,M,G,T, especially it is not allowed to be empty. Regards, Rainer
rotatelogs improvement
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
Re: rotatelogs improvement
glim wrote: 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. I'd vote for doing this on trunk, 2.2.x backport can be skipped or rethought once we have it working. -Paul
Re: rotatelogs improvement
glim schrieb: 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. Good idea. I take the opportunity to advertise my rotatelogs patch available at https://issues.apache.org/bugzilla/show_bug.cgi?id=44427 Regards, Rainer