Bug 50213 - mysterious apache crash with php4 and mysql
Summary: mysterious apache crash with php4 and mysql
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apache   
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-28 11:18 UTC by Trevor Cordes
Modified: 2007-04-18 16:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-21 10:52:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Trevor Cordes 2001-07-28 11:18:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
Either php4 or apache is crashing, and not leaving any log trail behind, 
except for weird mysql errors (see below).  Symptom: web browser will 
attempt to load a page hit for at least 30 minutes before giving up with 
error.  Symptom: a custom java app client that hits the web site for 
content does the same.  So far all the reports occur only on SSL protected 
https pages, though this might be a red herring as most page hits in this 
site are SSL.  At least 3 different php4 pages have shown this behaviour.  
Also maybe a red herring as those 3 pages are the most used.

How reproducible:

Steps to Reproduce:
1. hit the SSL pages a lot
2. eventually, very rarely, the page will not load, delaying nearly 
forever as described above.

Actual Results:  The page will not load, IE's world will spin for at least 
30 mins, or our java app waiting for the web response will hang.

Expected Results:  Page should load almost immediately.

Additional info:

Recently moved a production web server onto a fresh RH7.1 box.  After 2 
weeks of running there have built up a list of reports of this weird 
client-side problem.  There were no reports of this type of problem on our 
previous RH6.2 PHP3 server.


The apache access log will register the page hit right away as normal for 
one of these problematic hits.  No errors seem to be associated with these 
hits in the apache error log.

The only logged clue I get is mysterious mysql log errors:

010728  0:44:26  Aborted connection 533 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 
010728  0:44:27  Aborted connection 527 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 
010728  0:51:04  Aborted connection 537 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 
010728  0:58:32  Aborted connection 536 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 
010728  2:48:20  Aborted connection 535 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 
010728  3:01:36  Aborted connection 534 to db: 'warehouseone' 
user: 'warehouseone' host: `localhost' (Got an error reading communication 

There's consistently 100-200 of these errors in the log each day.  This 
could indicate that many problems per day, many of which may be happening 
to end users in which case I would not hear about them.  The reports I get 
are from internal users of the site and my own experiences.

When this bug happened to me personally today, I noted the time I started 
loading the page.  A mysql error did not show up in the log until 1.5 
hours later, and then there were many.  These mysql log errors seem to 
show up in bursts.  The mysql logs don't give me a way to correlate an 
entry with an exact apache hit, but I found it interesting there were no 
errors logged at all for 1.5 hours after my hit attempt.

There are no errors showing up in the php error log either.

Our scripts heavily use mysql and are quite complex.

Comment 1 Trevor Cordes 2001-08-10 08:40:17 UTC
Hello? Any thoughts?  If it means anything, we are using an actual store-bought
RH Pro Server retail version.

Comment 2 jon 2002-04-19 18:31:52 UTC
I'm also seeing this behavior on a production Red Hat 7.1 system, with all
updates installed. It seems to happen almost entirely when using SSL. It's
running older versions of HORDE/IMP, which I blamed originally, but as the
original bug states, the request is passed but then nothing happens. HTTP
processes seem to die left and right until only the master process is left. No
logged error messages of any kind; I'm not running MySQL in any related way, so
that's not the issue. Restarting HTTP solves the problem for a while, if you can
get all of the old HTTP processes to die first.

This is reproducible not all the time but pretty frequently. Next time it
happens, I'll try manually connecting with openssl s_client and see if I can
track the problem down further.

Comment 3 Joe Orton 2004-09-21 10:52:16 UTC
Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

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