You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ch...@apache.org on 2001/02/28 11:21:01 UTC
cvs commit: httpd-docs-1.3/htdocs/manual stopping.html.fr
cholet 01/02/28 02:21:01
Added: htdocs/manual stopping.html.fr
Log:
new French translation
Submitted by: Herve Dumont <hd...@club-internet.fr>
Reviewed by: Eric Cholet <ch...@logilune.com>
Revision Changes Path
1.1 httpd-docs-1.3/htdocs/manual/stopping.html.fr
Index: stopping.html.fr
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<!-- Traduction anglais 1.17 -->
<title>Arrêt et redémarrage d'Apache</title>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink=
"#000080" alink="#FF0000">
<!--#include virtual="header.html" -->
<h1 align="CENTER">Arrêt et redémarrage
d'Apache</h1>
<p>Ce document décrit l'arrêt et le
redémarrage d'Apache sur Unix seulement. Les utilisateurs
de Windows sont invités à lire le paragraphe <a
href="windows.html#signal">signaler à Apache en cours
d'exécution</a>.</p>
<p>Lorsque qu'Apache s'exécute, vous pouvez noter que
plusieurs processus <code>httpd</code> s'exécutent en
même temps sur votre machine, mais vous ne devez envoyer de
signaux qu'à celui dont l'identifiant de processus est
celui contenu dans le fichier <a href=
"mod/core.html#pidfile">PidFile</a>. Autrement dit, vous ne devez
jamais envoyer de signaux aux processus <code>httpd</code> autres
que le processus père. Il existe trois signaux que vous
pouvez envoyer au processus père : <code>TERM</code>,
<code>HUP</code>, et <code>USR1</code>, dont la signification est
décrite ci dessous.</p>
<p>Pour envoyer un signal au père vous pouvez utiliser une
commande comme</p>
<blockquote>
<pre>
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
</pre>
</blockquote>
Vous pouvez lire l'effet de la commande précédente
en effectuant la commande
<blockquote>
<pre>
tail -f /usr/local/apache/logs/error_log
</pre>
</blockquote>
Ces exemples devront être modifiés en fonction des
valeurs des directives <a href=
"mod/core.html#serverroot">ServerRoot</a> et <a href=
"mod/core.html#pidfile">PidFile</a>.
<p>Avec Apache 1.3 est fourni un script <a href=
"programs/apachectl.html">apachectl</a> qui peut être
employé pour démarrer, arrêter et relancer
Apache. Il peut nécessiter un peu d'adaptation pour votre
système, pour cela lisez les commentaires situés au
début de ce script.</p>
<h3>Signal TERM : arrêt immédiat</h3>
<p>L'envoi du signal <code>TERM</code> demande au processus
père d'essayer de tuer tous ses processus fils. Il peut
s'écouler quelques secondes avant que tous les processus
fils ne soient tués. Le processus père se termine
ensuite. Les requêtes en cours sont terminées et
plus aucune requête n'est traitée.</p>
<h3>Signal HUP : redémarrage immédiat</h3>
<p>L'envoi du signal <code>HUP</code> demande au processus
père de tuer tous ses processus fils, comme le signal
<code>TERM</code>, mais le processus père ne se termine
pas. Il relit ses fichiers de configuration, et rouvre les
fichiers de trace. Il lance ensuite un nouvel ensemble de
processus fils et continue de traiter les requêtes.</p>
<p>Les utilisateurs du module <a href=
"mod/mod_status.html">status</a> noteront que les statistiques du
serveur sont réinitialisées à zéro
après l'envoi du signal <code>HUP</code>.</p>
<p><strong>Note:</strong> si votre fichier de configuration
contient des erreurs lorsque vous demandez un redémarrage,
le processus père ne se relancera pas mais se terminera
avec une erreur. Voir plus bas pour une méthode permettant
d'éviter ce problème.</p>
<h3>Signal USR1 : redémarrage en douceur</h3>
<p><strong>Note:</strong> pour les versions inférieures
à 1.2b9 cette fonction est instable et ne doit pas être
utilisée.</p>
<p>Le signal <code>USR1</code> demande au processus père
de prier les processus de se terminer après avoir
traité leurs requêtes en cours (ou de se terminer
immédiatement s'ils n'ont pas de traitement en cours).
Le processus père relit les fichiers de configuration et
rouvre les fichiers de trace. Au fur et à mesure que les
fils meurent, ils sont remplacés par un processus fils
prenant en compte la nouvelle <em>génération</em>
de la configuration, qui commence aussitôt à traiter les
nouvelles requêtes.</p>
<p>Cette fonction est conçue pour toujours respecter les
valeurs de <a href="mod/core.html#maxclients">MaxClients</a>, <a
href="mod/core.html#minspareservers">MinSpareServers</a>, et <a
href="mod/core.html#maxspareservers">MaxSpareServers</a>. De
plus, elle respecte la valeur de <a href=
"mod/core.html#startservers">StartServers</a> de la
manière suivante : si après une seconde, au moins
StartServers nouveaux processus fils n'ont pas été
créés, alors elle en crée suffisament pour
combler le manque. Autrement dit, la fonction essaie de maintenir
à la fois le nombre de processus fils approprié
pour traiter la charge actuelle du serveur, et respecter vos
souhaits concernant le paramètre StartServers.</p>
<p>Les utilisateurs du module <a href=
"mod/mod_status.html">status</a> noteront que les statistiques du
serveur <strong>ne sont pas</strong> réinitialisées
à zéro après l'envoi du signal
<code>USR1</code>. La fonction est écrite afin de
minimiser le temps durant lequel le serveur est incapable de
traiter de nouvelles requêtes (elle sont mises en attente
par le système d'exploitation et donc ne sont pas perdues)
tout en respectant vos réglages. Pour cela, Apache doit
maintenir la <em>table de comunication interprocessus</em> pour
les différents processus fils et leur
génération.</p>
<p>Le module <a href="mod/mod_status.html">status</a> utilise
également un <code>G</code> pour marquer les fils traitant
les requêtes démarrées avant le
redémarrage en douceur.</p>
<p>Actuellement, il n'y a aucun moyen pour un script de rotation
des fichiers de trace qui utiliserait le signal <code>USR1</code>
de savoir de manière absolue que tous les processus fils
écrivant dans l'ancien fichier de trace sont
terminés. Nous suggérons d'utiliser un délai
d'attente raisonnable après l'envoi du signal avant de
faire quoi que ce soit avec l'ancien fichier de trace. Si par
exemple la majorité de vos accès sont
traités en moins de dix minutes pour des utilisateurs
utilisant des liaisons à bas débit, alors vous
devrez attendre quinze minutes avant de faire quelque chose avec
l'ancien fichier de trace.</p>
<p><strong>Note:</strong> Si votre fichier de configuration
contient des erreurs au moment de réinitialiser le
processus père, ce dernier ne redémarrera pas et se
terminera avec une erreur. Dans le cas d'un redémarrage en
douceur, le processus père laisse les fils continuer quand
il se termine. Ce sont les processus fils qui sont
"terminés en douceur" en traitant leurs requêtes en
cours. Ceci peut poser des problèmes si vous essayez de
redémarrer le serveur -- il ne sera pas capable de se
connecter sur son port d'écoute. Afin d'effectuer un
redémarrage, vous pouvez vérifier la syntaxe du
fichier de configuration en utilisant le paramètre
<code>-t</code> (cf. <a href="programs/httpd.html">httpd</a>).
Ceci n'est pas suffisant pour garantir que le serveur
redémarrera correctement. Afin de vérifier la
sémantique des fichiers de configuration ainsi que leur
syntaxe, vous pouvez essayer de lancer <code>httpd</code> sous un
compte utilisateur autre que root. S'il n'y a pas d'erreur, il
essaiera d'ouvrir ses ports réseau, mais échouera,
soit parce qu'il n'est pas root, soit parce que le serveur existant
est déjà connecté sur ces ports. S'il
échoue pour une autre raison, c'est qu'il existe une
erreur dans les fichiers de configuration et cette erreur doit
être corrigéavant de déclencher une relance
en douceur.</p>
<h3>Annexe : signaux et conditions temporelles</h3>
<p>Avant la version 1.2b9 d'Apache il existait un certain nombre
de <em>conditions temporelles</em> concernant les signaux de
redémarrage et d'arrêt. Une description simple d'une
condition temporelle est un problème lié à
l'ordre des traitements dans le temps, comme quand quelque chose
arrive au mauvais moment et ne se comporte pas comme
prévu). Pour les architectures possédant les
"bonnes" fonctionnalités, nous les avons
éliminées autant que possible. Mais il doit
être noté qu'il existe toujours des problèmes
sur certaines architectures.</p>
<p>Les architectures utilisant un fichier sur disque <a href=
"mod/core.html#scoreboardfile">ScoreBoardFile</a> pour la
communication interprocessus peuvent éventuellement
corrompre ce fichier. Il en résulte le message d'erreur
"bind: Address already in use" (après le signal
<code>HUP</code>) or "long lost child came home!" (après
le signal <code>USR1</code>). Le premier est une erreur fatale,
tandis que le deuxième a juste pour effet de perdre une
entrée dans la table de communication interprocessus. Il
est donc envisageable d'utiliser le redémarrage en
douceur, avec d'occasionnels redémarrages immédiats.
Ces problèmes sont très difficiles à
éviter, mais heureusement de nombreuses architectures n'ont
pas besoin d'utiliser un fichier pour la communication interprocessus.
Consulter la documentation sur <a href=
"mod/core.html#scoreboardfile">ScoreBoardFile</a> pour savoir si
votre architecture l'utilise.</p>
<p><code>NEXT</code> et <code>MACHTEN</code> (68k seulement)
présentent quelques conditions temporelles qui peuvent
provoquer la perte d'un signal d'arrêt ou de
redémarrage, mais ne devraient pas créer de
problèmes majeurs.</p>
<p>Sur toutes les architectures, les processus fils
présentent des conditions temporelles dans le cas du
traitement de la deuxième requête, et des suivantes,
pour des connexions HTTP persistantes (KeepAlive). Le processus
peut se terminer après avoir lu la requête mais
avant d'avoir lu l'en-tête. Il existe un correctif, mais
celui ci a été réalisé trop tard pour
être intégré dans la version 1.2. En
théorie, ceci ne doit pas être un problème
car le client utilisant la persistance des connexions doit
être capable de traiter ce genre de cas, qui peut se
produire soit à cause des temps de latence du réseau,
soit à cause des délais de réponse trop longs des
serveurs. En pratique, cela ne semble pas non plus affecter le
système. Dans un test, le serveur était
redémarré vingt fois par seconde et les clients ont
pu consulter le site sans obtenir de documents vides ou
d'images invalides.
</p>
<!--#include virtual="footer.html" -->
</body>
</html>