You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jonathan Swartz <sw...@pobox.com> on 2007/04/13 02:20:02 UTC

graceful stop?

I'm wondering if anyone uses Apache's graceful stop feature (http:// 
httpd.apache.org/docs/2.2/stopping.html#gracefulstop) with mod_perl  
servers.

The mod_perl guide section on starting and stopping (http:// 
perl.apache.org/docs/general/control/ 
control.html#Safe_Code_Updates_on_a_Live_Production_Server)  
recommends using regular old stop. Doesn't this terminate any current  
user requests, with ugly results on the client? Wouldn't it make more  
sense to issue a graceful stop signal, setting  
GracefulShutdownTimeout to a low number (like 1) and then sleeping  
for at least that number of seconds? This would give current requests  
some time to finish, while avoiding the problems of running multiple  
identically configured instances of httpd at the same time.

Thanks
Jon


Re: graceful stop?

Posted by Perrin Harkins <pe...@elem.com>.
On 4/13/07, Jonathan Swartz <sw...@pobox.com> wrote:
> It doesn't seem worth the risk, especially if
> GracefulStopTimeout is only 1 second. The server will be unable to respond
> for a second longer, but most load balancers should be able to react quickly
> to that. (I think).

I would definitely set it longer than 1 second.  I'd probably give it
at least 10.

Incidentally, I fake this in mod_perl 1 by having my server take down
the page that the load balancer uses to see if the machine is up, and
waiting 60 seconds before stopping the server.  This gives the load
balancer time to see the server is "down" and divert traffic, and lets
the current requests finish.  If you have multiple machines behind a
load balancer, this is a pretty safe way to do it.

- Perrin

Re: graceful stop?

Posted by Clinton Gormley <cl...@traveljury.com>.
On Thu, 2007-04-12 at 23:42 -0400, Perrin Harkins wrote:
> On 4/12/07, Jonathan Swartz <sw...@pobox.com> wrote:
> > The mod_perl guide section on starting and stopping (http://
> > perl.apache.org/docs/general/control/
> > control.html#Safe_Code_Updates_on_a_Live_Production_Server)
> > recommends using regular old stop. Doesn't this terminate any current
> > user requests, with ugly results on the client? Wouldn't it make more
> > sense to issue a graceful stop signal, setting
> > GracefulShutdownTimeout to a low number (like 1) and then sleeping
> > for at least that number of seconds?


I've started using it recently and it works well, but you MUST have a
GracefulShutdownTimeout set, otherwise the processes persist
indefinitely.  At least they do when you have mod_ssl loaded.

I would set the timeout higher than 1 though - eg 10 - this gives any
slow clients / requests (eg a large upload on a modem) time to complete.

There is no need to sleep - you can restart immediately.  The new apache
processes have nothing to do with the old ones, so they are completely
independent, and are able to bind the relevant ports.

So I do:
#  apachectl graceful-stop; apachectl start

works for me.

clint


Re: graceful stop?

Posted by Perrin Harkins <pe...@elem.com>.
On 4/12/07, Jonathan Swartz <sw...@pobox.com> wrote:
> The mod_perl guide section on starting and stopping (http://
> perl.apache.org/docs/general/control/
> control.html#Safe_Code_Updates_on_a_Live_Production_Server)
> recommends using regular old stop. Doesn't this terminate any current
> user requests, with ugly results on the client? Wouldn't it make more
> sense to issue a graceful stop signal, setting
> GracefulShutdownTimeout to a low number (like 1) and then sleeping
> for at least that number of seconds?

Yes.  The reason the docs don't suggest that is that this is a new
feature in apache 2.2 and as such has not been used by most people who
contribute to the docs.  Please try it, and if it works for you we'll
update the docs.

The graceful restart, which has been there for years, doesn't work
well with mod_perl because it doesn't actually create a new perl
interpreter, so all the old state is still there.

- Perrin