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 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`
Vous pouvez lire l'effet de la commande précédente
en effectuant la commande
tail -f /usr/local/apache/logs/error_log
Ces exemples devront être modifiés en fonction des
valeurs des directives ServerRoot et PidFile.
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.
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.
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.
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 un processus fils
prenant en compte la nouvelle génération
de la configuration, qui commence 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éavant de déclencher une relance
en douceur.
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èmes majeurs.
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.