mirror of
https://github.com/apache/httpd.git
synced 2025-08-20 16:09:55 +00:00
108e127781
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@934441 13f79535-47bb-0310-9956-ffa450edef68
265 lines
14 KiB
Plaintext
265 lines
14 KiB
Plaintext
<?xml version="1.0" encoding="ISO-8859-1" ?>
|
|
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
|
|
<!-- French translation : Lucien GENTIS -->
|
|
<!-- Reviewed by : Vincent Deffontaines -->
|
|
<!-- English Revision: 933544 -->
|
|
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one or more
|
|
contributor license agreements. See the NOTICE file distributed with
|
|
this work for additional information regarding copyright ownership.
|
|
The ASF licenses this file to You under the Apache License, Version 2.0
|
|
(the "License"); you may not use this file except in compliance with
|
|
the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
See the License for the specific language governing permissions and
|
|
limitations under the License.
|
|
-->
|
|
|
|
<manualpage metafile="stopping.xml.meta">
|
|
|
|
<title>Arrêt et redémarrage du serveur HTTP Apache</title>
|
|
|
|
<summary>
|
|
<p>Ce document couvre l'arrêt et le redémarrage du
|
|
serveur HTTP Apache sur
|
|
les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000
|
|
and XP doivent consulter
|
|
<a href="platform/windows.html#winsvc">Exécuter httpd en tant que
|
|
service</a> et les utilisateurs de Windows 9x et ME doivent consulter
|
|
<a href="platform/windows.html#wincons">Exécuter httpd comme une
|
|
application de type console</a> pour plus d'informations sur le contrôle
|
|
de httpd à partir de ces plateformes.</p>
|
|
</summary>
|
|
|
|
<seealso><program>httpd</program></seealso>
|
|
<seealso><program>apachectl</program></seealso>
|
|
<seealso><a href="invoking.html">Démarrage</a></seealso>
|
|
|
|
<section id="introduction"><title>Introduction</title>
|
|
|
|
<p>Afin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux
|
|
processus <program>httpd</program> en cours d'exécution. Les signaux
|
|
peuvent être envoyés de deux manières. Tout d'abord, vous pouvez
|
|
utiliser la commande unix <code>kill</code>
|
|
pour envoyer directement des signaux aux processus. Vous pouvez remarquer
|
|
que plusieurs processus <program>httpd</program> s'exécutent sur votre
|
|
système, mais il vous suffit d'envoyer les signaux au processus parent,
|
|
dont le PID est enregistré dans le fichier précisé par la directive
|
|
<directive module="mpm_common">PidFile</directive>. C'est à dire que vous
|
|
n'aurez jamais besoin d'envoyer des signaux à aucun de ces processus,
|
|
sauf au processus parent. Trois types de signaux peuvent être envoyés
|
|
au processus parent :
|
|
<code><a href="#term">TERM</a></code>,
|
|
<code><a href="#graceful">USR1</a></code>,
|
|
<code><a href="#hup">HUP</a></code>, et
|
|
<code><a href="#gracefulstop">WINCH</a></code>, qui
|
|
sera décrit plus loin.</p>
|
|
|
|
<p>Pour envoyer un signal au processus parent, vous devez entrer une commande
|
|
du style :</p>
|
|
|
|
<example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example>
|
|
|
|
<p>La seconde méthode permettant d'envoyer des signaux aux processus
|
|
<program>httpd</program>
|
|
consiste à utiliser les options de ligne de commande <code>-k</code> :
|
|
<code>stop</code>,
|
|
<code>restart</code>, <code>graceful</code> et <code>graceful-stop</code>,
|
|
comme décrit ci-dessous. Ce sont des arguments du binaire
|
|
<program> httpd</program>, mais il est recommandé de les utiliser
|
|
avec le script de contrôle <program>apachectl</program>, qui se
|
|
chargera de les passer à <program>httpd</program>.</p>
|
|
|
|
<p>Après avoir envoyé un signal à <program>httpd</program>, vous pouvez
|
|
suivre le cours de son action en entrant :</p>
|
|
|
|
<example>tail -f /usr/local/apache2/logs/error_log</example>
|
|
|
|
<p>Adaptez ces exemples en fonction de la définition de vos directives
|
|
<directive module="core">ServerRoot</directive> et
|
|
<directive module="mpm_common">PidFile</directive>.</p>
|
|
</section>
|
|
|
|
<section id="term"><title>Arrêter immédiatement</title>
|
|
|
|
<dl><dt>Signal: TERM</dt>
|
|
<dd><code>apachectl -k stop</code></dd>
|
|
</dl>
|
|
|
|
<p>L'envoi du signal <code>TERM</code> ou <code>stop</code> au
|
|
processus parent induit chez celui-ci une tentative immédiate
|
|
de tuer tous ses processus enfants. Cela peut durer plusieurs secondes.
|
|
Après cela, le processus parent lui-même se termine. Toutes les requêtes
|
|
en cours sont terminées, et plus aucune autre n'est traitée.</p>
|
|
</section>
|
|
|
|
<section id="graceful"><title>Redémarrage en douceur</title>
|
|
|
|
<dl><dt>Signal: USR1</dt>
|
|
<dd><code>apachectl -k graceful</code></dd>
|
|
</dl>
|
|
|
|
<p>L'envoi du signal <code>USR1</code> ou <code>graceful</code> au
|
|
processus parent lui fait envoyer aux processus enfants
|
|
<em>l'ordre</em> de se terminer une fois leur requête courante
|
|
traitée (ou de se terminer immédiatement s'ils n'ont plus rien à traiter).
|
|
Le processus parent relit ses fichiers de configuration et
|
|
réouvre ses fichiers de log. Chaque fois qu'un enfant s'éteint, le
|
|
processus parent le remplace par un processus
|
|
enfant de la nouvelle <em>génération</em> de la
|
|
configuration, et celui-ci commence immédiatement à traiter les
|
|
nouvelles requêtes.</p>
|
|
|
|
<p>Ce code est conçu pour toujours respecter la directive de contrôle
|
|
de processus des modules MPMs, afin que les nombres de processus et de
|
|
threads
|
|
disponibles pour traiter les demandes des clients soient maintenus à
|
|
des valeurs appropriées tout au long du processus de démarrage.
|
|
En outre, il respecte la directive
|
|
<directive module="mpm_common">StartServers</directive> de la manière
|
|
suivante : si après une seconde au moins <directive
|
|
module="mpm_common">StartServers</directive> nouveaux processus
|
|
enfants n'ont pas été créés, un nombre suffisant de processus
|
|
supplémentaires est créé pour combler le manque. Ainsi le code
|
|
tente de maintenir à la fois le nombre approprié de processus enfants
|
|
en fonction de la charge du serveur, et vos souhaits définis par la
|
|
directive <directive module="mpm_common">StartServers</directive>.</p>
|
|
|
|
<p>Les utilisateurs du module <module>mod_status</module>
|
|
noteront que les statistiques du serveur ne sont <strong>pas</strong>
|
|
remises à zéro quand un signal <code>USR1</code> est envoyé. Le code
|
|
a été conçu à la fois pour minimiser la durée durant laquelle le
|
|
serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en
|
|
file d'attente par le système d'exploitation, et ne sont ainsi jamais
|
|
perdues) et pour respecter vos paramètres de personnalisation.
|
|
Afin d'accomplir ceci, il doit conserver le
|
|
<em>tableau</em> utilisé pour garder la trace de tous les processus
|
|
enfants au cours des différentes générations.</p>
|
|
|
|
<p>Le module status utilise aussi un <code>G</code> afin d'indiquer
|
|
quels processus enfants ont encore des traitements de requêtes en cours
|
|
débutés avant que l'ordre graceful restart ne soit donné.</p>
|
|
|
|
<p>Pour l'instant, il est impossible pour un script de rotation
|
|
des logs utilisant
|
|
<code>USR1</code> de savoir de manière certaine si tous les processus
|
|
enfants inscrivant des traces de pré-redémarrage sont terminés.
|
|
Nous vous suggérons d'attendre un délai suffisant après l'envoi du
|
|
signal <code>USR1</code>
|
|
avant de faire quoi que ce soit avec les anciens logs. Par exemple,
|
|
si la plupart de vos traitements durent moins de 10 minutes pour des
|
|
utilisateurs empruntant des liaisons à faible bande passante, alors vous
|
|
devriez attendre 15 minutes avant de faire quoi que ce soit
|
|
avec les anciens logs.</p>
|
|
|
|
<note>
|
|
<p>Lorsque vous initiez un redémarrage, une vérification de
|
|
la syntaxe est tout d'abord effectuée, afin de s'assurer qu'il n'y a
|
|
pas d'erreurs dans les fichiers de configuration. Si votre fichier de
|
|
configuration comporte des erreurs de syntaxe, vous recevrez un message
|
|
d'erreur les concernant, et le serveur refusera de redémarrer. Ceci
|
|
permet d'éviter la situation où un serveur a
|
|
été arrêté et ne peut plus redémarrer,
|
|
et où vous vous retrouvez avec un serveur hors-service.</p>
|
|
|
|
<p>Ceci ne garantit pas encore que le serveur va redémarrer
|
|
correctement. Pour vérifier la sémantique des fichiers de configuration
|
|
en plus de leur syntaxe, vous pouvez essayer de démarrer
|
|
<program>httpd</program> sous un utilisateur non root.
|
|
S'il n'y a pas d'erreurs, il tentera d'ouvrir ses sockets et ses fichiers
|
|
de log et échouera car il n'a pas les privilèges root (ou parce que
|
|
l'instance actuelle de
|
|
<program>httpd</program> est déjà associée à ces ports). S'il échoue
|
|
pour toute autre raison, il y a probablement une erreur dans le
|
|
fichier de configuration et celle-ci doit être corrigée avant de lancer
|
|
le redémarrage en douceur.</p></note>
|
|
</section>
|
|
|
|
<section id="hup"><title>Redémarrer immédiatement</title>
|
|
|
|
<dl><dt>Signal: HUP</dt>
|
|
<dd><code>apachectl -k restart</code></dd>
|
|
</dl>
|
|
|
|
<p>L'envoi du signal <code>HUP</code> ou <code>restart</code> au
|
|
processus parent lui fait tuer ses processus enfants comme pour le signal
|
|
<code>TERM</code>, mais le processus parent ne se termine pas.
|
|
Il relit ses fichiers de configuration, et réouvre ses fichiers de log.
|
|
Puis il donne naissance à un nouveau jeu de processus enfants
|
|
et continue de traiter les requêtes.</p>
|
|
|
|
<p>Les utilisateurs du module <module>mod_status</module>
|
|
noteront que les statistiques du serveur sont remises à zéro quand un
|
|
signal <code>HUP</code> est envoyé.</p>
|
|
|
|
<note>Comme dans le cas d'un redémarrage "graceful", une
|
|
vérification de la syntaxe est effectuée avant que le
|
|
redémarrage ne soit tenté. Si votre fichier de configuration comporte
|
|
des erreurs de syntaxe, le redémarrage ne sera pas effectué, et
|
|
vous recevrez un message concernant ces erreurs.</note>
|
|
</section>
|
|
|
|
<section id="gracefulstop"><title>Arrêt en douceur</title>
|
|
|
|
<dl><dt>Signal : WINCH</dt>
|
|
<dd><code>apachectl -k graceful-stop</code></dd>
|
|
</dl>
|
|
|
|
<p>L'envoi du signal <code>WINCH</code> ou <code>graceful-stop</code>
|
|
au processus parent lui fait <em>aviser</em> les processus enfants
|
|
de s'arrêter après le traitement de leur requête en cours
|
|
(ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter).
|
|
Le processus parent va alors supprimer son fichier
|
|
<directive module="mpm_common">PidFile</directive> et cesser l'écoute
|
|
de tous ses ports. Le processus parent va continuer à s'exécuter,
|
|
et va surveiller les processus enfants
|
|
qui ont encore des requêtes à traiter. Lorsque tous les processus enfants
|
|
ont terminé leurs traitements et se sont arrêtés ou lorsque le délai
|
|
spécifié par la directive <directive
|
|
module="mpm_common">GracefulShutdownTimeout</directive> a été atteint,
|
|
le processus parent s'arrêtera à son tour. Si ce délai est atteint,
|
|
tout processus enfant encore en cours d'exécution se verra envoyer
|
|
le signal <code>TERM</code>
|
|
afin de le forcer à s'arrêter.</p>
|
|
|
|
<p>L'envoi du signal <code>TERM</code> va arrêter immédiatement
|
|
les processus parent et enfants en état "graceful". Cependant,
|
|
comme le fichier <directive module="mpm_common">PidFile</directive>
|
|
aura été supprimé, vous ne pourrez pas utiliser
|
|
<code>apachectl</code> ou <code>httpd</code> pour envoyer ce signal.</p>
|
|
|
|
<note><p>Le signal <code>graceful-stop</code> vous permet d'exécuter
|
|
simultanément plusieurs instances de <program>httpd</program>
|
|
avec des configurations identiques. Ceci s'avère une fonctionnalité
|
|
puissante quand vous effectuez des mises à jour "en douceur"
|
|
de httpd ; cependant, cela peut aussi causer des blocages fatals et des
|
|
situations de compétition (race conditions)
|
|
avec certaines configurations.</p>
|
|
|
|
<p>On a pris soin de s'assurer que les fichiers sur disque
|
|
comme les fichiers verrou (<directive
|
|
module="core">Mutex</directive>) et les fichiers socket Unix
|
|
(<directive module="mod_cgid">ScriptSock</directive>) contiennent le PID
|
|
du serveur, et coexistent sans problème. Cependant, si une directive de
|
|
configuration, un module tiers ou une CGI résidente utilise un autre
|
|
verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer
|
|
que chaque instance de <program>httpd</program> qui s'exécute
|
|
n'écrase pas les fichiers des autres instances.</p>
|
|
|
|
<p>Vous devez aussi prendre garde aux autres situations de compétition,
|
|
comme l'utilisation de l'enregistrement des logs avec un transfert de ceux-ci
|
|
dans le style <program>rotation des logs</program>. Plusieurs instances
|
|
du programme de <program>rotation des logs</program> qui tentent d'effectuer
|
|
une rotation des mêmes fichiers de log en même temps peuvent détruire
|
|
mutuellement leurs propres fichiers de log.</p></note>
|
|
</section>
|
|
|
|
</manualpage>
|