Apache HTTP Server

Arrêt et redémarrage d'Apache

Ce document décrit l'arrêt et le redémarrage d'Apache sur Unix et Cygwin seulement. Les utilisateurs de Windows sont invités à lire le paragraphe signaler à Apache en cours d'exécution.

Lorsque qu'Apache s'exécute, vous pouvez noter que plusieurs processus httpd 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 PidFile. Autrement dit, vous ne devez jamais envoyer de signaux aux processus httpd autres que le processus père. Il existe trois signaux que vous pouvez envoyer au processus père : TERM, HUP, et USR1, dont la signification est décrite ci dessous.

Pour envoyer un signal au père vous pouvez utiliser une commande comme

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

    tail -f /usr/local/apache/logs/error_log

Avec Apache 1.3 est fourni un script apachectl 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.

Signal TERM : arrêt immédiat

L'envoi du signal TERM 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.

Signal HUP : redémarrage immédiat

L'envoi du signal HUP demande au processus père de tuer tous ses processus fils, comme le signal TERM, 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.

Les utilisateurs du module status noteront que les statistiques du serveur sont réinitialisées à zéro après l'envoi du signal HUP.

Note: 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.

Signal USR1 : redémarrage en douceur

Note: pour les versions inférieures à 1.2b9 cette fonction est instable et ne doit pas être utilisée.

Le signal USR1 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 des processus fils prenant en compte la nouvelle génération de la configuration, et commencent aussitôt à traiter les nouvelles requêtes.

Cette fonction est conçue pour toujours respecter les valeurs de MaxClients, MinSpareServers, et MaxSpareServers. De plus, elle respecte la valeur de StartServers 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.

Les utilisateurs du module status noteront que les statistiques du serveur ne sont pas réinitialisées à zéro après l'envoi du signal USR1. 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 table de comunication interprocessus pour les différents processus fils et leur génération.

Le module status utilise également un G pour marquer les fils traitant les requêtes démarrées avant le redémarrage en douceur.

Actuellement, il n'y a aucun moyen pour un script de rotation des fichiers de trace qui utiliserait le signal USR1 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.

Note: 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 -t (cf. httpd). 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 httpd 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ée avant de déclencher une relance en douceur.

Annexe : signaux et conditions temporelles

Avant la version 1.2b9 d'Apache il existait un certain nombre de conditions temporelles 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.

Les architectures utilisant un fichier sur disque ScoreBoardFile 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 HUP) ou "long lost child came home!" (après le signal USR1). 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 ScoreBoardFile pour savoir si votre architecture l'utilise.

NEXT et MACHTEN (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ème majeur.

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.

Apache HTTP Server