Commit 4347866b authored by dgaudet's avatar dgaudet
Browse files

This documents graceful restarts, and the caveats associated with them. The 

graceful restart code itself isn't committed yet... and so this doc won't
be linked to until we commit the graceful restart code.

Reviewed by:
Submitted by:
Obtained from:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@77988 13f79535-47bb-0310-9956-ffa450edef68
parent 5c2d3176

docs/manual/stopping.html

0 → 100644
+137 −0
Original line number Diff line number Diff line 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML>

<HEAD>

<TITLE>Stopping and Restarting Apache</TITLE>

</HEAD>



<BODY>

<!--#include virtual="header.html" -->

<h1>Stopping and Restarting Apache</h1>



<p>You will notice many <code>httpd</code> executables running on your system,

but you should not send signals to any of them except the parent, whose

pid is in the <a href="mod/core.html#pidfile">PidFile</a>.  That is to

say you shouldn't ever need to send signals to any process except the

parent.  There are three signals that you can send the parent:

<code>TERM</code>, <code>HUP</code>, and <code>USR1</code>, which will

be described in a moment.



<p>To send a signal to the parent you should issue a command such as:

<blockquote><pre>

    kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`

</pre></blockquote>



You can read about its progress by issuing:



<blockquote><pre>

    tail -f /usr/local/etc/httpd/logs/error_log

</pre></blockquote>



Modify those examples to match your

<a href="mod/core.html#serverroot">ServerRoot</a> and

<a href="mod/core.html#pidfile">PidFile</a> settings.



<h3>TERM Signal: stop now</h3>



<p>Sending the <code>TERM</code> signal to the parent causes it to

immediately attempt to kill off all of its children.  It may take it

several seconds to complete killing off its children.  Then the

parent itself exits.  Any requests in progress are terminated, and no

further requests are served.



<h3>HUP Signal: restart now</h3>



<p>Sending the <code>HUP</code> signal to the parent causes it to kill off

its children like in <code>TERM</code> but the parent doesn't exit.  It

re-reads its configuration files, and re-opens any log files.

Then it spawns a new set of children and continues

serving hits.



<p>Users of the

<a href="mod/mod_status.html">status module</a>

will notice that the server statistics are

set to zero when a <code>HUP</code> is sent.



<h3>USR1 Signal: graceful restart</h3>



<p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and

shouldn't be used at all.



<p>The <code>USR1</code> signal causes the parent process to <i>advise</i>

the children to exit after their current request (or to exit immediately

if they're not serving anything).  The parent re-reads its configuration

files and re-opens its log files.  As each child dies off the parent

replaces it with a child from the new <i>generation</i> of the

configuration, which begins serving new requests immediately.



<p>This code is designed to always respect the

<a href="mod/core.html#maxclients">MaxClients</a>,

<a href="mod/core.html#minspareservers">MinSpareServers</a>,

and <a href="mod/core.html#maxspareservers">MaxSpareServers</a> settings.

Furthermore, it respects <a href="mod/core.html#startservers">StartServers</a>

in the following manner:  if after one second at least StartServers new

children have not been created, then create enough to pick up the slack.

This is to say that the code tries to maintain both the number of children

appropriate for the current load on the server, and respect your wishes

with the StartServers parameter.



<p>Users of the

<a href="mod/mod_status.html">status module</a>

will notice that the server statistics

are <b>not</b> set to zero when a <code>USR1</code> is sent.  The code

was written to both minimize the time in which the server is unable to serve

new requests (they will be queued up by the operating system, so they're

not lost in any event) and to respect your tuning parameters.  In order

to do this it has to keep the <i>scoreboard</i> used to keep track

of all children across generations.



<p>The status module will also use a <code>G</code> to indicate those

children which are still serving requests started before the graceful

restart was given.



<p>At present there is no way for a log rotation script using

<code>USR1</code> to know for certain that all children writing the

pre-restart log have finished.  We suggest that you use a suitable delay

after sending the <code>USR1</code> signal before you do anything with the

old log.  For example if most of your hits take less than 10 minutes to

complete for users on low bandwidth links then you could wait 15 minutes

before doing anything with the old log.



<h3>Appendix: signals and race conditions</h3>



<p>Prior to Apache 1.2b9 there were several <i>race conditions</i>

involving the restart and die signals (a simple description of race

condition is: a time-sensitive problem, as in if something happens at just

the wrong time it won't behave as expected).  For those architectures that

have the "right" feature set we have eliminated as many as we can.

But it should be noted that there still do exist race conditions on

certain architectures.



<p>Architectures that use an on disk <a

href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the potential

to lose track of a child during graceful restart (you'll see an <a

href="mod/core.html#errorlog">ErrorLog</a> message saying something about

a <i>long lost child</i>).  The ScoreBoardFile directive explains how

to figure out if your server uses a file, and possibly how to avoid it.

There is also the potential that the scoreboard will be corrupted during

any signalling, but this only has bad effects on graceful restart.



<p><code>NEXT</code> and <code>MACHTEN</code> have small race conditions

which can cause a restart/die signal to be lost, but should not cause the

server to do anything otherwise problematic.

<!-- they don't have sigaction, or we're not using it -djg -->



<p>All architectures have a small race condition in each child involving

the second and subsequent requests on a persistent HTTP connection

(KeepAlive).  It may exit after reading the request line but before

reading any of the request headers.  There is a fix that was discovered

too late to make 1.2.  In theory this isn't an issue because the KeepAlive

client has to expect these events because of network latencies and

server timeouts.  In practice it doesn't seem to affect anything either

-- in a test case the server was restarted twenty times per second and

clients successfully browsed the site without getting broken images or

empty documents.



<!--#include virtual="footer.html" -->

</BODY>

</HTML>

docs/manual/stopping.html.en

0 → 100644
+137 −0
Original line number Diff line number Diff line 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML>

<HEAD>

<TITLE>Stopping and Restarting Apache</TITLE>

</HEAD>



<BODY>

<!--#include virtual="header.html" -->

<h1>Stopping and Restarting Apache</h1>



<p>You will notice many <code>httpd</code> executables running on your system,

but you should not send signals to any of them except the parent, whose

pid is in the <a href="mod/core.html#pidfile">PidFile</a>.  That is to

say you shouldn't ever need to send signals to any process except the

parent.  There are three signals that you can send the parent:

<code>TERM</code>, <code>HUP</code>, and <code>USR1</code>, which will

be described in a moment.



<p>To send a signal to the parent you should issue a command such as:

<blockquote><pre>

    kill -TERM `cat /usr/local/etc/httpd/logs/httpd.pid`

</pre></blockquote>



You can read about its progress by issuing:



<blockquote><pre>

    tail -f /usr/local/etc/httpd/logs/error_log

</pre></blockquote>



Modify those examples to match your

<a href="mod/core.html#serverroot">ServerRoot</a> and

<a href="mod/core.html#pidfile">PidFile</a> settings.



<h3>TERM Signal: stop now</h3>



<p>Sending the <code>TERM</code> signal to the parent causes it to

immediately attempt to kill off all of its children.  It may take it

several seconds to complete killing off its children.  Then the

parent itself exits.  Any requests in progress are terminated, and no

further requests are served.



<h3>HUP Signal: restart now</h3>



<p>Sending the <code>HUP</code> signal to the parent causes it to kill off

its children like in <code>TERM</code> but the parent doesn't exit.  It

re-reads its configuration files, and re-opens any log files.

Then it spawns a new set of children and continues

serving hits.



<p>Users of the

<a href="mod/mod_status.html">status module</a>

will notice that the server statistics are

set to zero when a <code>HUP</code> is sent.



<h3>USR1 Signal: graceful restart</h3>



<p><b>Note:</b> prior to release 1.2b9 this code is quite unstable and

shouldn't be used at all.



<p>The <code>USR1</code> signal causes the parent process to <i>advise</i>

the children to exit after their current request (or to exit immediately

if they're not serving anything).  The parent re-reads its configuration

files and re-opens its log files.  As each child dies off the parent

replaces it with a child from the new <i>generation</i> of the

configuration, which begins serving new requests immediately.



<p>This code is designed to always respect the

<a href="mod/core.html#maxclients">MaxClients</a>,

<a href="mod/core.html#minspareservers">MinSpareServers</a>,

and <a href="mod/core.html#maxspareservers">MaxSpareServers</a> settings.

Furthermore, it respects <a href="mod/core.html#startservers">StartServers</a>

in the following manner:  if after one second at least StartServers new

children have not been created, then create enough to pick up the slack.

This is to say that the code tries to maintain both the number of children

appropriate for the current load on the server, and respect your wishes

with the StartServers parameter.



<p>Users of the

<a href="mod/mod_status.html">status module</a>

will notice that the server statistics

are <b>not</b> set to zero when a <code>USR1</code> is sent.  The code

was written to both minimize the time in which the server is unable to serve

new requests (they will be queued up by the operating system, so they're

not lost in any event) and to respect your tuning parameters.  In order

to do this it has to keep the <i>scoreboard</i> used to keep track

of all children across generations.



<p>The status module will also use a <code>G</code> to indicate those

children which are still serving requests started before the graceful

restart was given.



<p>At present there is no way for a log rotation script using

<code>USR1</code> to know for certain that all children writing the

pre-restart log have finished.  We suggest that you use a suitable delay

after sending the <code>USR1</code> signal before you do anything with the

old log.  For example if most of your hits take less than 10 minutes to

complete for users on low bandwidth links then you could wait 15 minutes

before doing anything with the old log.



<h3>Appendix: signals and race conditions</h3>



<p>Prior to Apache 1.2b9 there were several <i>race conditions</i>

involving the restart and die signals (a simple description of race

condition is: a time-sensitive problem, as in if something happens at just

the wrong time it won't behave as expected).  For those architectures that

have the "right" feature set we have eliminated as many as we can.

But it should be noted that there still do exist race conditions on

certain architectures.



<p>Architectures that use an on disk <a

href="mod/core.html#scoreboardfile">ScoreBoardFile</a> have the potential

to lose track of a child during graceful restart (you'll see an <a

href="mod/core.html#errorlog">ErrorLog</a> message saying something about

a <i>long lost child</i>).  The ScoreBoardFile directive explains how

to figure out if your server uses a file, and possibly how to avoid it.

There is also the potential that the scoreboard will be corrupted during

any signalling, but this only has bad effects on graceful restart.



<p><code>NEXT</code> and <code>MACHTEN</code> have small race conditions

which can cause a restart/die signal to be lost, but should not cause the

server to do anything otherwise problematic.

<!-- they don't have sigaction, or we're not using it -djg -->



<p>All architectures have a small race condition in each child involving

the second and subsequent requests on a persistent HTTP connection

(KeepAlive).  It may exit after reading the request line but before

reading any of the request headers.  There is a fix that was discovered

too late to make 1.2.  In theory this isn't an issue because the KeepAlive

client has to expect these events because of network latencies and

server timeouts.  In practice it doesn't seem to affect anything either

-- in a test case the server was restarted twenty times per second and

clients successfully browsed the site without getting broken images or

empty documents.



<!--#include virtual="footer.html" -->

</BODY>

</HTML>