On Mon, Oct 11, 2004 at 10:09:30PM -0400, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > >>>>Sorry, but you didn't understand what I was trying to say. Let's say > >>>>you have only one process with many threads. If that process grows > >>>>too big (since you can't measure a size of a thread) it'll throw the > >>>>TERM signal and then it'll block until all threads are done. > >>>>Meanwhile no other new requests will be started. Or will the parent > >>>>process spawn a new process as soon as its child receives SIGTERM? I > >>>>can't see how the parent will know about it, before the child > >>>>terminates. > > > >Yes, the situation you just described is correct. In the case of one > >child and multiple threads, sending a SIGTERM is not a very good idea.
(untested) What if the child forks? The child (parent of grandchild) could then _exit, and the main httpd would detect that it needs to spawn a new child. The grandchild would continue serving the request, after setting $r->connection->keepalive = AP_CONN_CLOSE; # ?? available in mod_perl ?? $r->child_terminate(); There is a memory exhaustion potential if the grandchild can be tied up for a very long time, and the new child serving requests can be caused to exceed its memory limit and to fork and do the same, etc until there are many, many grandchildren all tying up lots of memory. So in the case of a single child we have to balance two types of DoS: - stop serving requests until we can cleanly exit and start fresh (a la graceful restart) - risk memory exhaustion DoS from forking and finishing up in background Therefore, sending SIGTERM might be the way to go, but to mitigate the DoS potential of not serving requests for too long, an alarm should be set after which the child will abort requests in progress. To make that solution even better, it would be nice if MPMs supported some sort of command to disable keepalives on all current connections, so that each thread finishes up as soon as it has finished serving requests in progress. As an alternative to setting an alarm to make sure that new requests are not starved for too long, one could risk memory exhaustion DoS instead by forking and setting the alarm in the grandchild. In most cases, this would mean that new requests continue to be served without delay and grandchild finishes up old requests. However, the worst-case scenario of the grandchild taking a long time to exit and many grandchildren building up and causing a memory DoS is probably worse than temporarily delaying serving new connections. Take your pick. > But this is exactly the same situation with N child processes. It's quite > possible that all N processes will get SIGTERM in about the same time. That sounds like proper behavior, though. Stop serving requests until excessive resource usage is released, right? Cheers, Glenn --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
