You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Juerg Umhang <ju...@solnet.ch> on 2007/04/20 10:46:31 UTC
RFE -- external overload procedure
hello
please consider this posting as a request for enhancement
httpd knows about his overload situation.
---- [error] server reached MaxClients setting, consider raising the
MaxClients setting
this overload is easily created by an external attacker. in case of an
attack you have to react.
best done on a lower osi-layer (iptables, pf, ...).
realtime log analysis has his own odds and twists. we would prefer a call
to an 'external helper procedure'.
the following patch is a quick and dirty implementation.
--- httpd-2.2.4/server/mpm/worker/worker.c.orig 2007-04-12
12:58:28.000000000 +0200
+++ httpd-2.2.4/server/mpm/worker/worker.c 2007-04-12
15:44:04.000000000 +0200
@@ -135,6 +135,7 @@ static fd_queue_t *worker_queue;
static fd_queue_info_t *worker_queue_info;
static int mpm_state = AP_MPMQ_STARTING;
static int sick_child_detected;
+static int reported = 0;
/* The structure used to pass unique initialization info to each thread */
typedef struct {
@@ -1514,7 +1515,6 @@ static void perform_idle_server_maintena
/* terminate the free list */
if (free_length == 0) {
/* only report this condition once */
- static int reported = 0;
if (!reported) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0,
@@ -1522,6 +1522,10 @@ static void perform_idle_server_maintena
"server reached MaxClients setting, consider"
" raising the MaxClients setting");
reported = 1;
+ if(!fork()) {
+ system("/usr/local/bin/apache_overload");
+ exit(0);
+ }
}
idle_spawn_rate = 1;
}
@@ -1550,6 +1554,7 @@ static void perform_idle_server_maintena
}
else if (idle_spawn_rate < MAX_SPAWN_RATE) {
idle_spawn_rate *= 2;
+ reported = 0;
}
}
}
in this context we have some questions:
-- do you think it makes sense to implement this feature ?
-- could it be done in a module (without the overhead of going through the
scoreboard for each pre_connection call) ?
-- can we expect this enhancement in a future release ?
btw: we hope to see separately configurable timeouts (
http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon.
kind regards
juerg
-- input validation is for people who can't do forensics!
internet storm center at sans.org
Re: RFE -- external overload procedure
Posted by Jim Jagielski <ji...@jaguNET.com>.
It would be best, I think, if the patches actually used normal
httpd coding standards... The whole MAX_OVLP_LINE stuff is very
out of place.
On Apr 25, 2007, at 10:02 AM, Juerg Umhang wrote:
> its now in bugzilla. patches submitted
> http://issues.apache.org/bugzilla/show_bug.cgi?id=42216
>
> -- juerg
>
>> On 4/20/07, Juerg Umhang <ju...@solnet.ch> wrote:
>>> hello
>>>
>>> please consider this posting as a request for enhancement
>>>
>>> httpd knows about his overload situation.
>>> ---- [error] server reached MaxClients setting, consider raising the
>>> MaxClients setting
>>> this overload is easily created by an external attacker. in case
>>> of an
>>> attack you have to react.
>>> best done on a lower osi-layer (iptables, pf, ...).
>>> realtime log analysis has his own odds and twists. we would prefer a
>>> call
>>> to an 'external helper procedure'.
>>
>>> in this context we have some questions:
>>> -- do you think it makes sense to implement this feature ?
>>> -- could it be done in a module (without the overhead of going
>>> through
>>> the
>>> scoreboard for each pre_connection call) ?
>>
>> It is reasonable to me for httpd to provide a module interface (hook)
>> so that a third-party module can take action when httpd reaches the
>> MaxClients (Unix) or ThreadsPerChild (Windows) condition. (Maybe the
>> hook just provides some basic statistics, and the module can
>> determine
>> whether the absolute limit has been reached or its own configurable
>> threshhold has been reached.)
>>
>> A way that a module can do something reasonable without modifying the
>> server is to create a separate child process that monitors the
>> scoreboard at its own interval, and takes whatever action is
>> appropriate. That check can be infrequent enough that the
>> performance
>> overhead is negligible.
>>
>>> -- can we expect this enhancement in a future release ?
>>
>> Some other committer can speak for themselves, but I wouldn't expect
>> it without a patch submitted.
>>
>>> btw: we hope to see separately configurable timeouts (
>>> http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon.
>>
>> I don't recall anyone here interested in fulfilling the goal
>> expressed
>> in that comment.
>>
>
>
Re: RFE -- external overload procedure
Posted by Juerg Umhang <ju...@solnet.ch>.
its now in bugzilla. patches submitted
http://issues.apache.org/bugzilla/show_bug.cgi?id=42216
-- juerg
> On 4/20/07, Juerg Umhang <ju...@solnet.ch> wrote:
>> hello
>>
>> please consider this posting as a request for enhancement
>>
>> httpd knows about his overload situation.
>> ---- [error] server reached MaxClients setting, consider raising the
>> MaxClients setting
>> this overload is easily created by an external attacker. in case of an
>> attack you have to react.
>> best done on a lower osi-layer (iptables, pf, ...).
>> realtime log analysis has his own odds and twists. we would prefer a
>> call
>> to an 'external helper procedure'.
>
>> in this context we have some questions:
>> -- do you think it makes sense to implement this feature ?
>> -- could it be done in a module (without the overhead of going through
>> the
>> scoreboard for each pre_connection call) ?
>
> It is reasonable to me for httpd to provide a module interface (hook)
> so that a third-party module can take action when httpd reaches the
> MaxClients (Unix) or ThreadsPerChild (Windows) condition. (Maybe the
> hook just provides some basic statistics, and the module can determine
> whether the absolute limit has been reached or its own configurable
> threshhold has been reached.)
>
> A way that a module can do something reasonable without modifying the
> server is to create a separate child process that monitors the
> scoreboard at its own interval, and takes whatever action is
> appropriate. That check can be infrequent enough that the performance
> overhead is negligible.
>
>> -- can we expect this enhancement in a future release ?
>
> Some other committer can speak for themselves, but I wouldn't expect
> it without a patch submitted.
>
>> btw: we hope to see separately configurable timeouts (
>> http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon.
>
> I don't recall anyone here interested in fulfilling the goal expressed
> in that comment.
>
Re: RFE -- external overload procedure
Posted by Jeff Trawick <tr...@gmail.com>.
On 4/20/07, Juerg Umhang <ju...@solnet.ch> wrote:
> hello
>
> please consider this posting as a request for enhancement
>
> httpd knows about his overload situation.
> ---- [error] server reached MaxClients setting, consider raising the
> MaxClients setting
> this overload is easily created by an external attacker. in case of an
> attack you have to react.
> best done on a lower osi-layer (iptables, pf, ...).
> realtime log analysis has his own odds and twists. we would prefer a call
> to an 'external helper procedure'.
> in this context we have some questions:
> -- do you think it makes sense to implement this feature ?
> -- could it be done in a module (without the overhead of going through the
> scoreboard for each pre_connection call) ?
It is reasonable to me for httpd to provide a module interface (hook)
so that a third-party module can take action when httpd reaches the
MaxClients (Unix) or ThreadsPerChild (Windows) condition. (Maybe the
hook just provides some basic statistics, and the module can determine
whether the absolute limit has been reached or its own configurable
threshhold has been reached.)
A way that a module can do something reasonable without modifying the
server is to create a separate child process that monitors the
scoreboard at its own interval, and takes whatever action is
appropriate. That check can be infrequent enough that the performance
overhead is negligible.
> -- can we expect this enhancement in a future release ?
Some other committer can speak for themselves, but I wouldn't expect
it without a patch submitted.
> btw: we hope to see separately configurable timeouts (
> http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon.
I don't recall anyone here interested in fulfilling the goal expressed
in that comment.