Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
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 Ex�cuter httpd en tant que service et les utilisateurs de Windows 9x et ME doivent consulter Ex�cuter httpd comme une application de type console pour plus d'informations sur le contr�le de httpd � partir de ces plateformes.
Introduction Arr�ter imm�diatement Red�marrage en douceur Red�marrer imm�diatement Arr�t en douceur
Afin d'arr�ter ou red�marrer le serveur HTTP Apache, vous devez envoyer un signal aux
processus httpd 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 kill
pour envoyer directement des signaux aux processus. Vous pouvez remarquer
que plusieurs processus httpd 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
PidFile. 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 :
TERM,
USR1,
HUP, et
WINCH, qui
seront d�crit plus loin.
Pour envoyer un signal au processus parent, vous devez entrer une commande du style :
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
La seconde m�thode permettant d'envoyer des signaux aux processus
httpd
consiste � utiliser les options stop,
restart, graceful et
graceful-stop du commutateur -k de la ligne
de commande comme d�crit ci-dessous. Ce sont des arguments du binaire
httpd, mais il est recommand� de les utiliser
avec le script de contr�le apache2ctl, qui se
chargera de les passer � httpd.
Apr�s avoir envoy� un signal � httpd, vous pouvez
suivre le cours de son action en entrant :
tail -f /usr/local/apache2/logs/error_log
Adaptez ces exemples en fonction de la d�finition de vos directives
ServerRoot et
PidFile.
apache2ctl -k stopA la r�ception du signal TERM ou stop,
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.
apache2ctl -k gracefulA la r�ception du signal USR1 ou
graceful, le
processus parent envoie aux processus enfants
l'ordre 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 g�n�ration de la
configuration, et celui-ci commence imm�diatement � traiter les
nouvelles requ�tes.
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
StartServers de la mani�re
suivante : si apr�s une seconde au moins StartServers 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 StartServers.
Les utilisateurs du module mod_status
noteront que les statistiques du serveur ne sont pas
remises � z�ro quand un signal USR1 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
tableau utilis� pour garder la trace de tous les processus
enfants au cours des diff�rentes g�n�rations.
Dans son �tat des processus,
le module status utilise aussi un caract�re G 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�.
Pour l'instant, il est impossible pour un script de rotation
des logs utilisant
USR1 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 USR1
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.
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.
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
httpd 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
httpd 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.
apache2ctl -k restartA la r�ception du signal HUP ou
restart, le
processus parent tue ses processus enfants comme pour le signal
TERM, 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.
Les utilisateurs du module mod_status
noteront que les statistiques du serveur sont remises � z�ro quand un
signal HUP est envoy�.
apache2ctl -k graceful-stopA la r�ception du signal WINCH ou
graceful-stop, le
processus parent ordonne � 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
PidFile 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 GracefulShutdownTimeout 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 TERM
afin de le forcer � s'arr�ter.
L'envoi du signal TERM va arr�ter imm�diatement
les processus parent et enfants en �tat "graceful". Cependant,
comme le fichier PidFile
aura �t� supprim�, vous ne pourrez pas utiliser
apache2ctl ou httpd pour envoyer ce signal.
Le signal graceful-stop vous permet d'ex�cuter
simultan�ment plusieurs instances de httpd
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.
On a pris soin de s'assurer que les fichiers sur disque
comme les fichiers verrou (Mutex) et les fichiers socket Unix
(ScriptSock) 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 httpd qui s'ex�cute
n'�crase pas les fichiers des autres instances.
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 rotatelogs. Plusieurs instances
du programme rotatelogs 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.