<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 655319:883878 (outdated) -->
+<!-- English Revision : 1174747 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<manualpage metafile="stopping.xml.meta">
- <title>Arrêt et redémarrage</title>
+ <title>Arrêt et redémarrage du serveur HTTP Apache</title>
<summary>
- <p>Ce document couvre l'arrêt et le redémarrage d'Apache sur
+ <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 Apache en tant que
+ <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 Apache comme une
+ <a href="platform/windows.html#wincons">Exécuter httpd comme une
application de type console</a> pour plus d'informations sur le contrôle
- d'Apache à partir de ces plateformes.</p>
+ de httpd à partir de ces plateformes.</p>
</summary>
<seealso><program>httpd</program></seealso>
<section id="introduction"><title>Introduction</title>
- <p>Afin d'arrêter ou redémarrer Apache, vous devez envoyer un signal aux
+ <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>
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 :
+ <directive module="mpm_common">PidFile</directive>. Autrement dit, vous
+ n'aurez jamais besoin d'envoyer des signaux à aucun des
+ processus enfants, mais seulement 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
<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
+ <p>A la réception du signal <code>TERM</code> ou <code>stop</code>,
+ le processus parent tente immédiatement
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>
<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
+ <p>A la réception du signal <code>USR1</code> ou
+ <code>graceful</code>, le
+ processus parent envoie 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
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
+ Pour y parvenir, 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
+ <p>Dans son état des processus,
+ 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>
<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
+ <p>A la réception du signal <code>HUP</code> ou
+ <code>restart</code>, le
+ processus parent tue 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
<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
+ <p>A la réception du signal <code>WINCH</code> ou
+ <code>graceful-stop</code>, le
+ processus parent <em>avise</em> ses 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
<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" d'Apache;
- cependant, cela peut aussi causer des blocages fatals et des
+ 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 ceux définis par les directives
- <directive module="core">Lockfile</directive> et
- <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
+ 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>
projects / apache / blobdiff