On 5/1/06, Greg Ames [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
after more thought, there is a simpler patch that should do the job. the key
to both of
these is how threads in SERVER_DEAD state with a pid in the scoreboard are
treated. this
means that p_i_s_m forked on a previous timer
Jeff Trawick wrote:
On 5/1/06, Greg Ames [EMAIL PROTECTED] wrote:
after more thought, there is a simpler patch that should do the job. the
key to both of
these is how threads in SERVER_DEAD state with a pid in the scoreboard are
treated. this
means that p_i_s_m forked on a previous
On 5/2/06, Chris Darroch [EMAIL PROTECTED] wrote:
If you can bear with me for a day or two more, I should have
a collection of patches ready. These tackle the issue by
tracking the start and listener threads in a nice new spot in
the scoreboard, and also clean up various issues and bugs
Jeff Trawick wrote:
I have been working with a user on one of these fork bomb scenarios
and assumed it was the child_init hook. But after giving them a test
fix that relies on a child setting scoreboard fields in child_main
before child-init hooks run, and also adds some debugging traces
Colm:
The worker and event MPMs would use these to track their
non-worker threads; and the parent process for these MPMs could
monitor them as per option C to decide when the child process's
workers were ready to be counted.
+1, I think this could be very useful, I came accross the same
On Sat, Apr 15, 2006 at 10:20:29AM -0400, Chris Darroch wrote:
Re my option C, it also occurs to me that instead of squeezing
the worker MPM's start and listener threads into extra, internal
worker_score structures, it might be more appropriate to create a
new section of the scoreboard with
Hi --
Someone tried to send me a fax in the middle of the night,
so I've been up for a while and I think I've realized there are
several subtle contention issues involved with any fix for this issue.
First of all, I should note that my initial patch in Bugzilla
has a flaw; it needs an else
Hi --
for (i = 0; i ap_threads_per_child; i++) {
if (status != SERVER_GRACEFUL status != SERVER_DEAD) {
ap_update_child_status_from_indexes(slot, i, SERVER_INIT, NULL);
}
}
[snip]
... after make_child() does its check for != GRACEFUL and != DEAD ...
After heading back
On 4/11/06, Chris Darroch [EMAIL PROTECTED] wrote:
Hi --
Alexander Lazic wrote:
After 'make install' i started apache, then some seconds later i got the
message '...MaxClients reached...' but there was no entry in the access
log, and nobody have make a request to this server.
Jeff
Jeff Trawick wrote:
There are problems accounting for child processes which are trying to
initialize that result in the parent thinking it needs to create more
children. The less harmful flavor is when it thinks (incorrectly) it
is already at MaxClients and issues the reached MaxClients
Hi --
Alexander Lazic wrote:
After 'make install' i started apache, then some seconds later i got the
message '...MaxClients reached...' but there was no entry in the access
log, and nobody have make a request to this server.
Jeff Trawick wrote:
There are problems accounting for child
11 matches
Mail list logo
