httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32239] - Server reached MaxClients setting on FreeBSD
Date Thu, 06 Jan 2005 14:40:48 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32239>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32239





------- Additional Comments From trawick@apache.org  2005-01-06 15:40 -------
Hi, Dejan,

Your last PR update says "All others just hung there." when referring to getting
backtraces of httpd child processes with gdb.  So I presume that gdb never
attached successfully but instead the last message it issued was something like
this?
"Attaching to program `/mnt/solaris9root/scratch/inst/21/bin/httpd', process 15015"
and never anything else.

If gdb is unable to get a backtrace since it can't attach to the process, try
killing a particular child process to generate a core file then use gdb to get
the backtrace from the core file.

Does your Apache dump core when a child process crashes?  Hopefully yes, so
force a core file like this:

a) during the hang condition, pick an httpd child process at random (call it pid
12345 in this example)
b) kill -SEGV 12345
c) gdb /path/to/httpd /path/to/corefile
Now run the gdb "where" command to get the backtrace.  It should show where the
code was stuck, preventing request processing from completing.

If your Apache doesn't dump core when a child process crashes, you need some
reconfiguring.

a) set CoredumpDirectory directive to a directory with free space which httpd
child processes can write to (e.g., "CoredumpDirectory /tmp)
b) make sure you have "ulimit -c unlimited" in the shell used to start Apache
c) try to force core again by sending a child process SIGSEGV

--/--

A totally different approach to finding out what code is hanging is to see what
requests are hanging using mod_status.

mod_backdoor (see http://www.apache.org/~trawick/mod_backdoor.txt) can allow you
to get mod_status reports even if the web server is hung on the normal ports.

Otherwise, you have to monitor mod_status reports over time to see what requests
are getting stuck.  You'll likely see more and more requests getting stuck
leading up to the time when no new connections can be processed.

--/--

It is very unlikely that anything in Apache is causing the problem.  You've
tried Apache 1.3 and Apache 2.0 and both eventually hit the MaxClients
condition.  A permanent MaxClients condition like this almost always means that
some dynamic content generator is hung.  Your PHP scripts are the common
denominator between the two failing configurations.  The above debugging
(getting backtrace at time of hang or finding out if specific requests are
hanging) can help point the way to which script(s) may be having a problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message