Bug 90584 - Apache Server Process Hanging in "Sending Reply" Phase
Apache Server Process Hanging in "Sending Reply" Phase
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: httpd (Show other bugs)
9
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-09 16:20 EDT by Thomas J. Baker
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-12 09:22:00 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 Thomas J. Baker 2003-05-09 16:20:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
I've searched bugzilla but didn't see anything like this. I've got apache 2.0
server running, pushing static HTML pages and one perl CGI
program. What happens is that httpd processes apparently get hung in the
"Sending Reply" phase. This causes the master httpd process to keep spawning
sub-processes until it hits 152 processes (two more than the config file
MaxClient limit of 150). It then stops serving any data at all.

The system is a dual CPU i686 with 0.5GB memory.

/etc/init.d/httpd fullstatus before reaching the 150 limit gives the
following scoreboard:

                      Apache Server Status for localhost
 
   Server Version: Apache/2.0.40 (Red Hat Linux)
   Server Built: Apr 7 2003 09:19:34
     _________________________________________________________________
 
   Current Time: Friday, 09-May-2003 10:15:12 EDT
   Restart Time: Thursday, 08-May-2003 22:18:13 EDT
   Parent Server Generation: 0
   Server uptime: 11 hours 56 minutes 59 seconds
   Total accesses: 75 - Total Traffic: 271 kB
   CPU Usage: u.28 s.28 cu.03 cs.04 - .00146% CPU load
   .00174 requests/sec - 6 B/second - 3700 B/request
   126 requests currently being processed, 9 idle workers
 
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW_W_
_______.........................................................
................................................................
 
   Scoreboard Key:
   "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
   "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
   "C" Closing connection, "L" Logging, "G" Gracefully finishing,
   "I" Idle cleanup of worker, "." Open slot with no current process
 

After that it lists all the busy processes and what they are sending. In my
case, it's all different types of files including jpgs and html
files. It's not any one file, it's not the single CGI program, it's
basically everything.

This site worked fine with Apache 1.3.X. I tried switching to the
'worker' version and although that version doesn't spawn a bunch of
processes, it still reports stuck processes like the normal version.

Version-Release number of selected component (if applicable):
kernel-smp-2.4.20-9, httpd-2.0.40-21.1

How reproducible:
Always

Steps to Reproduce:
1. See Description.
2.
3.
    

Additional info: I'd call this a high priority bug since my web server is
essentially useless at the moment.
Comment 1 Joe Orton 2003-05-12 07:52:47 EDT
Can you attach your httpd.conf and error_log?
Comment 2 Thomas J. Baker 2003-05-12 09:11:44 EDT
In trying to get the error log and conf files together to send to you, I noticed
that I didn't have the full path to /usr/sbin/rotatelogs in a log directive,
just "|roratelogs logfilename". No error messages were printed on a
"/etc/init.d/httpd configtest" but no logs were being generated either. After I
fixed that, the problem went away. Sorry for wasting your time but this may come
up for someone else.
Comment 3 Joe Orton 2003-05-12 09:22:00 EDT
OK, thanks.  httpd-2.0.45 upstream has better reporting of failures to spawn
piped log programs.

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