Serveur Apache HTTP Version 2.2
Ce document couvre l'arr�t et le red�marrage d'Apache sur les syst�mes Unix et similaires. Les utilisateurs de Windows NT, 2000 and XP doivent consulter Ex�cuter Apache en tant que service et les utilisateurs de Windows 9x et ME doivent consulter Ex�cuter Apache comme une application de type console pour plus d'informations sur le contr�le d'Apache � partir de ces plateformes.
Afin d'arr�ter ou red�marrer Apache, vous devez envoyer un signal aux
processus httpd
en cours d'ex�cution. Les signaux
peuvent �tre envoy�s de deux mani�res. Tout d'abord, vous pouvez
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
. C'est � dire que vous
n'aurez jamais besoin d'envoyer des signaux � aucun de ces processus,
sauf au processus parent. Trois types de signaux peuvent �tre envoy�s
au processus parent :
TERM
,
USR1
,
HUP
, et
WINCH
, qui
sera 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 de ligne de commande -k
:
stop
,
restart
, graceful
et graceful-stop
,
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 apachectl
, 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
.
apachectl -k stop
L'envoi du signal TERM
ou stop
au
processus parent induit chez celui-ci une tentative imm�diate
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.
apachectl -k graceful
L'envoi du signal USR1
ou graceful
au
processus parent lui fait envoyer 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 vos souhaits d�finis 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.
Afin d'accomplir ceci, il doit conserver le
tableau utilis� pour garder la trace de tous les processus
enfants au cours des diff�rentes g�n�rations.
Le module status utilise aussi un 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.
-t
(voir httpd
).
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'erreurs, 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.apachectl -k restart
L'envoi du signal HUP
ou restart
au
processus parent lui fait tuer 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�.
apachectl -k graceful-stop
L'envoi du signal WINCH
ou graceful-stop
au processus parent lui fait aviser les 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
apachectl
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" d'Apache;
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 ceux d�finis par les directives
Lockfile
et
ScriptSock
contiennent le PID
du serveur dans leurs noms donc ils 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'utilisation de l'enregistrement des logs avec un transfert de ceux-ci
dans le style rotation des logs
. Plusieurs instances
du programme de rotation des logs
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.