stopping.html.fr

Herve Dumont 25 Feb 2001 09:31:07 -0000

Here is a new submission. 
I've got a problem with the translation of "race condition". 
I wrote "conditions temporelles" but I don't like it.
The ESTI translation talks about "contraintes temporelles critiques" or  
"contraintes critiques", but it doesn't seem better.


Any suggestions ?

Herve

Title: Arrêt et redémarrage d'Apache

Arrêt et redémarrage d'Apache

Ce document décrit l'arrêt et le redémarrage d'Apache sur Unix seulement. Les utilisateur 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 envoyez de signaux qu'à celui dont l'identifiant de processus est celui ci contenu par le fichier PidFile. Autrement dit, vous ne devez jamais envoyer de signaux aux processus httpd si ce n'est 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 fonctions 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.

Signal TERM : arrêt immédiat

L'envoi du signal TERM demande au processus père d'essayer de tuer tous ces processus fils. Il peut se dérouler 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 ces 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 nouveau 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 afin d'éviter ce problème.

Signal USR1 : redémarrage en douceur

Note: pour les version inférieure 1.2b9 cette fonction est instable et devrait 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 si ils n'ont pas de traitements 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 aussitot à 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 soir 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 devriez attendre quinze minutes avant de faire quelquechosee avec l'ancien fichier de trace.

Note: Si votre fichier de configuration contient des erreurs au moment de réinitialisaer le processus père, celui 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 autre compte utilisateur que root. Si il n'y a pas d'erreurs, il essaiera d'ouvrir ses ports réseau, mais échouera, soit car il n'est pas root, soit parce que le serveur existant est déjà connecté sur ces ports. Si il échoue pour une autre raison, c'est qu'il existe une erreur dans les fichiers de configuration et cette erreur devrait être avant de déclencher une ralnce 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) or "long lost child came home!" (après le signal USR1). Le premier est une erreur fatale, tandis que la 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émarrage immédiat. Ces problèmes sont très difficiles à éviter, mais heureusement beaucoup d'architectures n'ont pas besoin de tenir un fichier pour la communication. Pour cela 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 connexion doit être capable de traiter ce genre de cas, ceux ci pouvant arriver soit à cause des temps de latence du réseau soit à des délais de réponse trop long 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 consulté le site sans obtenir de documents vides ou d'images invalides.