The following reply was made to PR mod_log-any/2026; it has been noted by GNATS.
From: Marc Slemko <[EMAIL PROTECTED]> To: Rob Mela <[EMAIL PROTECTED]> Cc: Apache bugs database <[EMAIL PROTECTED]> Subject: Re: mod_log-any/2026: Max log file size is 2,147,483,616 (2^31 - 32) bytes Date: Wed, 1 Apr 1998 14:13:26 -0700 (MST) On Wed, 1 Apr 1998, Rob Mela wrote: > > > I am using my own log format, and I'm pretty sure it is longer than the > CLF. I have some options there for saving space. But, the 2 gig limit was > reached after 8 or 9 million hits, which occurred only as a result of one > night's log rotation and server restart not running. > > I'd thought about two things: > > - logging to a pipe to gzip or a program that does file rotations > - hacking the log module to log directly to a database > - hacking the log module to do automatic log rotations > > I'd prefer to avoid pipes or a database. I see the simplest solutions as > the least error-prone and most recoverable --and a direct file write seems > the simplest. > > My first choice is automatic rotations. Fewer moving parts, and no need to > restart the server. I don't like restarting the server during the day > (approx 90 hits per second), since I think a lot of people will be getting > timeouts (it takes a minute or two to get up to speed again). Rotate your logs more often using SIGUSR1. See http://www.apache.org/docs/stopping.html for details. It doesn't cause the same disruption that a HUP does, but it means you have to be more careful about touching the old logs afterwards for a while since hits will still get written to them for a bit until all the old children exit. 1.2.x shouldn't take that long to get up to speed iff your StartServers is high enough; if not, then it will because it will only start a new process once every second. 1.3 does exponential spawning, so behaves much better under such situations. There is a rotatelogs in the support directory that can run from a pipe, but it looks a bit pokey for high volumes and you still have potential issues with piped logs and 1.2. In 1.3, using piped logs is really a very good solution and is very reliable and flexible.
