Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
Langues Disponibles: tr
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 comme une application de type console pour plus d'informations sur le contrôle de httpd à partir de ces plateformes.
Afin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux processus 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.
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 PidFile.
apache2ctl -k stop
A 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 graceful
A 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.
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 ante, 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 refa 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 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 restart
A 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-stop
A 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 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 ca 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 (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 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.
Langues Disponibles: tr