Project

General

Profile

Bug #1357

mod_evasive, max-conns-per-ip and max-worker

Added by Anonymous about 12 years ago. Updated over 3 years ago.

Status:
Wontfix
Priority:
High
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

As you know, when we use spawned server using max-worker directive, the mod_status wont work correctly.
in fact it shows status generated by child that responses request to server-status url.

i can establish up to 64 connection to lighty right now, but not at first request, maybe 2 or more retries.

-- ip_moosa

History

#1

Updated by darix about 12 years ago

  • Status changed from New to Fixed
  • Resolution set to wontfix

it is know that mod_status doesnt work correctly with multiple workers. and it cant be easily fixed. for now this is a wontfix.

for the matter mod_status in apache is as unreliable as ours with multiple workers.

#2

Updated by Anonymous over 11 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (wontfix)

Dear Jan and Darix, its 9 month later but still wontfix!

Im using lighty to serve my majox forum and download server and i've trouble with max-worker
on both servers i cant handle request with one worker due to really high traffic
on download server max connection per ip aint working and its killing lighty
on forum server i cant check server status when forum is over DOS/DDOS http attacks
thought this is one of most defects with lighty

I see this cant be patched easily but i hope lighttpd developers plan to fix it at least for next gold release

Regards

-- Moosa <ip_moosa

#3

Updated by Anonymous over 11 years ago

No any respond!?

-- Moosa <ip_moosa

#4

Updated by hoffie over 11 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to wontfix

What's so hard about getting the meaning of "wontfix"? lighttpd was not intended to be a multi-process application in the first place, max-workers was just introduced as it seemed to help some people. I'd rather call it a hack than a feature, because it makes lots of things way harder in lighty.

mod_status cannot be fixed easily, you would need some way of maintaining state between the two (or more) processes in a very fast way, as you can never guess which request will hit which lighty instance.

1.5 has multi-threaded I/O and should make max-workers (and all it's problems) obsolete. So this is still a WONTFIX in 1.4 (and you can't workaround it either). It's still WONTFIX in 1.5 but there is an easy workaround (don't use max-workers, instead increase I/O threads).

#5

Updated by hoffie over 11 years ago

Same applies to mod_evasive, of course.

#6

Updated by stbuehler almost 11 years ago

  • Status changed from Fixed to Wontfix

Also available in: Atom