| <?xml version="1.0" ?> |
| <!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 : 1174747 --> |
| |
| <!-- |
| 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. La |
| première méthode consiste à |
| 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>. Autrement dit, vous |
| n'aurez jamais besoin d'envoyer des signaux à aucun des |
| processus enfants, mais seulement au processus parent. Quatre 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 |
| seront 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 <code>stop</code>, |
| <code>restart</code>, <code>graceful</code> et |
| <code>graceful-stop</code> du commutateur <code>-k</code> de la ligne |
| de commande 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>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> |
| </section> |
| |
| <section id="graceful"><title>Redémarrage en douceur</title> |
| |
| <dl><dt>Signal: USR1</dt> |
| <dd><code>apachectl -k graceful</code></dd> |
| </dl> |
| |
| <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 |
| 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 le nombre de processus défini 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. |
| 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>Dans son état des processus, |
| le module status utilise aussi un caractère <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'erreur, 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>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 |
| 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>A la réception du signal <code>WINCH</code> ou |
| <code>graceful-stop</code>, le |
| processus parent <em>ordonne</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 |
| <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'enregistrement des logs avec un transfert de ceux-ci |
| via un pipe vers le programme <program>rotatelogs</program>. Plusieurs instances |
| du programme <program>rotatelogs</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> |
