Stas Bekman wrote:
Philippe M. Chiasson wrote: [...]
Second, you will get a child that gets to cleanly shutdown, however the child chooses to do that.
like what?
I just meant that calling exit() by ourselves is possibly causing a child process to exit before having been
able to do various cleanup tasks a child does. Looking at the various mpm modules, I can see in worker,
for instance, a child wanting to update it's state in the scoreboard before shutting itself down.
How does it deal with processes that segfault? Does the scoreboard gets out of sync if there is a segfault and it still thinks that there are processes around, which are gone since long...
There is nothing critical going on there. The parent is absolutely capable of dealing with childs that just vanish. I was just pointing
out that signal vs. calling exit() was just allowing for the child to perform what would seem to be like a cleaner shutdown in the
absence of a proper API for child termination.
You've forgotten to reply to this part.For a threaded MPM like prefork, we currently have no valid solution to
implement child_terminate() in order to reclaim memory. This way would at
least provide a partial solution. If a child grows to fat, calling $r->child_terminate()
would guarantee that that child will not serve new requests (keepalive issues exluded)
and kill itself off as soon as it can.
But it's very dangerous. Assume that you have N processes with M threads. If all processes will be scheduled to be killed, you will have a long long time w/o the server accepting any new requests.
No, no, only the child process will do that, the parent, and all the other
siblings will keep on hapilly serving requests.
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.
Once again, we can just go the original way and support this _only_ for non-threaded MPMs. Would work perfectly fine for prefork, and
wouldn't need to call exit() directly or to mess around trying to push a pool cleanup handler and insure its the last cleanup to get run.
Oh, it's definitely better if we can get an ap_ api for this, and I am plannnig on either writing on or at least pigningSo may be there is a need to expose it via a proper ap_ api?
the folks at httpd-dev about it. I was merely proposing a suggestion that might just fit our needs for now, while we
are looking for the best solution.
using a api call vs. signals is not the same thing, so I'm not sure it's a good temporary solution in case we are going to have a proper api call.
In my opinon, the here are the various solutions in order of preference 1. Call an ap_* function 2. Send a SIGTERM 3. Call exit() directly
And most likely, 2 & 3 only make sense for non-threaded MPMs
signature.asc
Description: OpenPGP digital signature
