Bug 62712 - Apache won't log to file beyond 2GB
Apache won't log to file beyond 2GB
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: apache (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
: 68345 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-04 14:39 EST by ctolley
Modified: 2007-04-18 12:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-31 05:06:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ctolley 2002-04-04 14:39:26 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
Once apache logfile reaches 2GB in size, it begins to accumulate errors like 
the following:

child pid 29561 exit signal File size limit exceeded (25)

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Pad/create logfile to just under 2GB
2. Start Apache and create traffic to produce more logs
3. Tail main error log for errors
	

Actual Results:  On a heavy traffic server, once the log threashold is reached, 
pages are still served but the excessive child exits cause it to be sluggish.
 

Expected Results:  There is no longer a 2GB filesize limit for Linux under 2.4 
kernels.  Is there a way to get Apache to recognize and log beyond 2GB?

Additional info:

If httpd should receive a HUP, USR1, or undergo a complete restart, httpd will 
fail to start with the following error in the virtual's error log:

[error] (27)File too large: could not open transfer log 
file /var/log/httpd/virt_combo.log.

This 2GB limit is being reached even with daily log rotation.  The site doesn't 
consitantly reach the 2GB mark, but they come close very often.  I have since 
doubled log rotation for apache (twice per day) to avoid this problem.
Comment 1 ctolley 2002-04-04 14:41:57 EST
Overlooked the Apache version info:

Apache-1.3.22-2
Comment 2 Warren Togami 2002-04-21 03:25:38 EDT
This just occured to us at http://www.amdmb.com.  Server slowed to a crawl and 
weird database errors (PHP & MySQL with vBulletin) started to occur where 
certain rows wouldn't UPDATE.

Rotated the massive log out and everything is now back to normal.
Comment 3 Matthias Saou 2002-05-22 07:03:58 EDT
I've had a similar problem with the error_log : When it reached 2GB, all httpd
processes just died. I have logging turned of on many servers since both
access_log (lots of traffic) and error_log (stupid debug info from perl modules)
reached 2GB in less than a day.

I thought it might have been a limit introduced when recompiling the source rpm
to raise the hard server limit, but seeing this bugzilla entry, I guess not.

Matthias
Comment 4 Warren Togami 2002-05-31 05:06:37 EDT
nalin@redhat.com, has this been fixed yet?
Comment 5 Joe Orton 2002-07-08 11:42:49 EDT
I doubt this is going to get fixed soon: an httpd binary compiled with large
file support would become incompatible with any modules which weren't compiled
with large file support.   The workaround (to rotate logs more often!) is
probably the only option in the short term.
Comment 6 Joe Orton 2002-07-10 08:34:02 EDT
*** Bug 68345 has been marked as a duplicate of this bug. ***
Comment 7 Warren Togami 2002-07-10 08:41:38 EDT
Would this not be a possible DoS attack?  Theoretically you cannot depend on
rotating "more often" because a hostile attacker could easily fill up the logs
to the 2GB breaking point.  This may be a DoS because when it hits the 2GB mark,
server performance crumbles while sometimes processes die, and strange things
occur with certain scripts where  database updates do not occur, only INSERT.  I
can't explain why this occurs... I just know that these things happened to me.
Comment 8 Warren Togami 2002-07-10 08:42:22 EDT
Does Apache 2.0 in Limbo still have this restriction?  Just wondering.
Comment 9 Matthias Saou 2002-07-10 08:43:37 EDT
Well, I see that I'm not the only one this is a problem for. The workaround of
rotating logs more often is obviously what I try to do, but when for whatever
reason a logfile does get to 2GB, my expected behaviour would be to have apache
stop logging to that file, but not crash!

I'm absolutely sure that I've had some web servers running (maybe compiled from
source?) that didn't crash when the 2GB limit was reached, as it sometime
happened that I would discover it a week later (the most recent timestamp in the
log being one wek old) with the server still running fine, only having log
entries lost.

I doulbt this crash is normal, and although I understand that it may not be
possible to easily add support for > 2GB files, this should definitely be
considered a bug and fixed as such!
Comment 10 Joe Orton 2002-07-10 09:01:22 EDT
Fair points; a better workaround to "rotating more often" would be to use piped
logs + a rotatelogs process: the stock Apache rotatelogs will truncate the file
and start again once a write files, which is certainly a better failure mode.

The 2.0 package in Limbo has the same restrictions as 1.3 unfortunately; filing
an RFE against that package would be appreciated.
Comment 11 Joe Orton 2002-07-19 17:29:23 EDT
My previous comment (which meant to say "when a write fails" not files) is not
correct, I hadn't realized that the process segfaults when reaching the 2gb limit. 

Another option is to compile the rotatelogs binary with large file support
(should be a simple case of adding "#define _FILE_OFFSET_BITS 64" before the
#includes).
Comment 12 ctolley 2002-07-22 15:55:02 EDT
I posted an RFE on Apache's site linking to this bug report.  Here's the URL:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11053
Comment 13 Joe Orton 2002-07-22 18:43:57 EDT
I actually meant to file an RFE in bugzilla.redhat.com against the httpd
package, which I have now done as bug 69520.

Note You need to log in before you can comment on or make changes to this bug.