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: Sometimes 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. 3. 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. Versions: php-4.0.4pl1-9 php-mysql-4.0.4pl1-9 apache-1.3.19-5 mysql-3.23.36-1 mysql-server-3.23.36-1 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 packets) 010728 0:44:27 Aborted connection 527 to db: 'warehouseone' user: 'warehouseone' host: `localhost' (Got an error reading communication packets) 010728 0:51:04 Aborted connection 537 to db: 'warehouseone' user: 'warehouseone' host: `localhost' (Got an error reading communication packets) 010728 0:58:32 Aborted connection 536 to db: 'warehouseone' user: 'warehouseone' host: `localhost' (Got an error reading communication packets) 010728 2:48:20 Aborted connection 535 to db: 'warehouseone' user: 'warehouseone' host: `localhost' (Got an error reading communication packets) 010728 3:01:36 Aborted connection 534 to db: 'warehouseone' user: 'warehouseone' host: `localhost' (Got an error reading communication packets) 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.
Hello? Any thoughts? If it means anything, we are using an actual store-bought RH Pro Server retail version.
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.
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.