![[APACHE DOCUMENTATION]](images/sub.gif)
Vous pourrez constater que de nombreux exécutables httpd tournent sur votre système, cependant vous ne devrez envoyer des signaux qu'au processus père, dont le
PID est noté dans le fichier PidFile. De toutes façons, vous ne devriez jamais avoir à envoyer des signaux à aucun des processus fils. Pour ce qui est du père, vous pouvez utiliser trois signaux :
TERM, HUP, and USR1, que nous allons décrire ci-après.
Pour envoyer un signal au père, vous devrez exécuter une commande du type :
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
tail -f /usr/local/apache/logs/error_log
L'envoi du signal TERM au processus père lui demande de tenter de tuer
immédiatement tous ses fils. Cela peut prendre néanmoins plusieurs secondes. Enfin, le processus père lui-même s'arrête. Toute requête en cours est servie, toute nouvelle requête est ignorée.
L'envoi du signal HUP au processus prère lui demande de tuer tous ses fils comme pour le signal TERM mais le processus père ne s'arrête pas. A la place, il relit ses fichiers de configuration, rouvre tous les fichiers de trace. puis lance un nouvel ensemble de fils et continue de traiter les requêtes.
Les utilisateurs du module status
noteront que les statistiques du serveur sont réinitialisées après qu'un signal HUP a été traité.
Note : si votre fichier de configuration comporte des erreurs lorsque vous redémarrez, le processus père ne pourra continuer sa réinitialisation, et sortira avec un code d'erreur. Voir ci-après pour une méthode qui permet d'éviter ce désagrément.
Note : avant la version 1.2b9 ce signal produit une grande instabilité et ne devra donc pas être utilisé.
L'envoi du signal USR1 oblige le père de demander
à ses fils de s'arrêter après fin du traitement de la requête courante (ou de s'arrêter immédiatement si ils n'ont rien en cours de traitement). Le père relit ses fichiers de configuration et rouvre ses fichiers de trace. Au fur et à mesure que les fils meurent, le père les remplace par un nouveau fils basé sur la nouvelle configuration, lequel commence à traiter les requêtes immédiatement.
Cette procédure est prévue pour toujours respecter les conditions MaxClients, MinSpareServers, et MaxSpareServers. Elle respecte en outre la condition StartServers de la manière suivante : si après au moins une seconde, "StartServers" nouveaux fils n'ont pas été créés, alors elle en crée suffisament pour compléter sa réserve. C'est à dire que le programme essaie d'obtenir le nombre de fils suffisant pour supporter la charge courante du serveur, tout en respectant vos désirs exprimés par le paramètre StartServers.
Les utilisateurs du module status s'appercevront de nouveau que les statistiques serveur ne sont pas réinitialisées lorsqu'un tel signal est utilisé. Le code a été écrit de telle sorte que le temps pendant lequel le serveur ne peut plus servir de requêtes soit réduit au minimum (les requêtes seront tamponnées par le système d'exploitation, et donc aucun événement ne sera perdu) tout en respectant vos réglages. Pour cela, Apache doit maintenir l'ouverture du scoreboard afin de garder une vue sur tous les processus, ancienne ou nouvelle génération.
Le module d'états (status) marquera aussi un G pour indiquer quels fils
continuent a servir des requêtes sous l'ancienne configuration et écrive les résultats dans l'ancien fichier de trace.
Au jour d'aujourd'hui, il n'y a aucun moyen pour un script qui utiliserait les signaux USR1 de savoir de manière sûre à quel moment les fils ancienne génération sont tous remplacés. Nous suggérons que vous donniez un délai raisonnable suite à l'envoi dun signal USR1 avant que vous n'exploitiez l'ancienne trace. Par exemple, si la plupart de vos requêtes sont servies en environ 10 minutes à des utilisateurs connectés sur des liaisons à très bas débit, alors il sera judicieux de donner un temps d'attente de 15 minutes avant d'ouvrir l'ancien fichier de trace.
Note : Si votre fichier de configuration comporte des erreurs lorsque vous réinitialisez le processus père, alors ce dernier ne redémarrera pas, et s'arrêtera avec uncode d'erreur. Si la procédure conduisant à l'erreur était un redémarrage "en douceur", les fils continueront à tourner lorsque le père s'arrête. (Il s'agit des anciens fils qui n'avaient pas été encore remplacés, et qui terminaient le traitement des requêtes en cours).
Ceci va causer un problème lorsque vous tenterez de redémarrer le serveur -- il ne pourra plus effectuer l'assignation des ports à "écouter". Actuellement, la seule façon d'éviter ce cas est de bien vérifier la syntaxe de vos fichiers avant de redémarrer le serveur. Une bonne méthode est de faire tourner un httpd sous un utilisateur autre que root. Si il n'y a pas d'erreurs dans le fichier de configuration, il essaiera de mettre en place ses sockets et d'ouvrir les fichiers de configuration, et échouera naturellement puisqu'il n'est pas root (ou parceque le serveir opérationnel utilise déjà les même ports). Si la cause d'erreur est autre, il y a de forte chance que les fichiers de configuration présentent des fautes de syntaxe, et il sera bon de les corriger avant d'utiliser ces nouveaux fichiers pour redémarrer "en douceur" le serveur opérationnel.
Avant la version 1.2b9 d'Apache, il existait un certain nombre de contraintes temporelles critiques à propos des redémarrages et signaux d'arrêt (une définition simple d'une contrainte temporelle critique est : un problème lié a un mauvais séquencement temporel d'actions, soit une action qui est effectuée à un moment non adéquat). Pour les architectures présentant les caractéristiques "nominales", nous avons pu en éliminer le plus que nous pouvions. Il doit être noté que certaines architectures posent encore certains problèmes de contraintes temporelles critiques.
Les architectures utilisant un fichier ScoreBoardFile sur disque
présentent le danger de voir ce "scoreboard" altéré. Il peut en résulter des erreurs de type "bind: Address already in use" (après usage d'un signal HUP) ou
"long lost child came home!" (après usage d'un signal USR1). Le premier cas est une erreur fatale, le deuxième ne provoque que la perte d'une position de scoreboard
par le serveur. Il devra être envisagé de procéder courament à des redémarrages "en douceur", avec quelques redémarrages "hard" occasionnels. Ces problèmes sont très délicats à corriger, mais heureusement, de nombreuses architectures n'utilisent pas un tel fichier "scoreboard".
Voir la documentation sur les ScoreBoardFiles pour déterminer si votre système utilise ce fichier ou non.
NEXT et MACHTEN (68k seulement) présentent des contraintes critiques légères qui peuvent provoquer la perte d'un signal d'arrêt/redémarrage, mais ne devraient pas provoquer de faute majeure sur le serveur.
Sur toutes les architectures, les fils présentent des contraintes temporelles légères impliquant le traitement d'une seconde requête immédiatement subséquente à une connexion HTTP rémanente (KeepAlive). Le processus en question peut se terminer après avoir lu la ligne de requête, mais avant d'avoir lu la moindre ligne de l'en-tête de requête. C'est un bogue qui a été découvert trop tard pour la version 1.2. En practique cela ne semble pas affecter le fonctionnement global -- dans une de nos configurations de test, le serveur a été redémarré à peu près vingt fois par seconde sans que les clients n'ait été bloqués ni n'aient obtenu d'images cassées ou de documents vides --.
Version française © Valery Fremaux / EISTI 1998