You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2001/04/17 20:58:59 UTC
Apache 2.0.17 tarballs up
Doug reported some shutdown problems right after the tag, so this is probably not a good beta
candidate. If you disagree, please VOTE!
Bill
Re: Apache 2.0.17 tarballs up
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Doug MacEachern wrote:
> > In my tests, the kids eventually went down. The messages and extra kills
> > were mostly just an annoyance.
>
> much more than annoyance, we're talking 10+ seconds for the parent to
> finally send a SIGKILL to the children, then all the children hang around
> as defunct processes for a while longer. this happens with both prefork
> and threaded. i'm testing with vanilla builds, no extra modules added,
> default configuration other than changing the port. start the server, do
> not even make a single request (the kids are not processing anything), try
> to kill `cat logs/httpd.pid`, the problem is there.
Aha, I just duplicated what you are talking about. Apparently something regressed
before I committed. I had this working so that the kill -TERM `cat logs/httpd.pid`
worked (sometimes spitting out some "SIGTERM" messages), and never left kids
around.
The problem you are seeing is one that I encountered but had fixed. I'll take a
look at my development machine when I get home tomorrow and see what I missed.
You are right, this is more than annoying.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Apache 2.0.17 tarballs up
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> Looking through the code, we are doing graceful shutdowns in all cases on
> the prefork MPM. That is incorrect. SIGHUP should be a graceless
> shutdown.
Yeah, I removed the direct signal based shutdown for all of the idle server
maintenance stuff since it caused the deadlock, but I went too far and
removed the SIGHUP parts as well. I'll look at putting that part back in.
I believe the problem in the threaded mpm is the same (too much graceless
code removed).
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: Apache 2.0.17 tarballs up
Posted by rb...@covalent.net.
On Tue, 17 Apr 2001, Doug MacEachern wrote:
> On Tue, 17 Apr 2001, Paul J. Reder wrote:
>
> > I saw some cases where the kids were slow to shut down during testing.
> > What I found was that since the kids are not shutdown directly via
> > signal, but indirectly via flag, some of the kids took a little longer
> > than before. The kids a now allowed to finish their processing. This is
> > the nature of the fix to avoid the deadlock that occurred when they were
> > shutdown immediately.
> >
> > This is why I shifted the point in the switch statement to delay the time
> > period before Apache complained and SIGTERMed (or SIGKILLed) again.
> >
> > In my tests, the kids eventually went down. The messages and extra kills
> > were mostly just an annoyance.
>
> much more than annoyance, we're talking 10+ seconds for the parent to
> finally send a SIGKILL to the children, then all the children hang around
> as defunct processes for a while longer. this happens with both prefork
> and threaded. i'm testing with vanilla builds, no extra modules added,
> default configuration other than changing the port. start the server, do
> not even make a single request (the kids are not processing anything), try
> to kill `cat logs/httpd.pid`, the problem is there.
Looking through the code, we are doing graceful shutdowns in all cases on
the prefork MPM. That is incorrect. SIGHUP should be a graceless
shutdown.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Apache 2.0.17 tarballs up
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 17 Apr 2001, Paul J. Reder wrote:
> I saw some cases where the kids were slow to shut down during testing.
> What I found was that since the kids are not shutdown directly via
> signal, but indirectly via flag, some of the kids took a little longer
> than before. The kids a now allowed to finish their processing. This is
> the nature of the fix to avoid the deadlock that occurred when they were
> shutdown immediately.
>
> This is why I shifted the point in the switch statement to delay the time
> period before Apache complained and SIGTERMed (or SIGKILLed) again.
>
> In my tests, the kids eventually went down. The messages and extra kills
> were mostly just an annoyance.
much more than annoyance, we're talking 10+ seconds for the parent to
finally send a SIGKILL to the children, then all the children hang around
as defunct processes for a while longer. this happens with both prefork
and threaded. i'm testing with vanilla builds, no extra modules added,
default configuration other than changing the port. start the server, do
not even make a single request (the kids are not processing anything), try
to kill `cat logs/httpd.pid`, the problem is there.
Re: Apache 2.0.17 tarballs up
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Bill Stoddard wrote:
>
> Doug reported some shutdown problems right after the tag, so this is probably not a good beta
> candidate. If you disagree, please VOTE!
>
> Bill
I saw some cases where the kids were slow to shut down during testing.
What I found was that since the kids are not shutdown directly via
signal, but indirectly via flag, some of the kids took a little longer
than before. The kids a now allowed to finish their processing. This is
the nature of the fix to avoid the deadlock that occurred when they were
shutdown immediately.
This is why I shifted the point in the switch statement to delay the time
period before Apache complained and SIGTERMed (or SIGKILLed) again.
In my tests, the kids eventually went down. The messages and extra kills
were mostly just an annoyance.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein