Arrêt et redémarrage - Serveur Apache HTTP

Serveur Apache HTTP Version 2.2

Apache > Serveur HTTP > Documentation > Version 2.2

# Arrêt et redémarrage

Langues Disponibles: de | en | es | fr | ja | ko | tr

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.

### Voir aussi

- `httpd`
- `apachectl`
- Démarrage

## Introduction

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`.

## Arrêter immédiatement

Signal: TERM
  `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.

## Redémarrage en douceur

Signal: USR1
  `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.

Si votre fichier de configuration comporte des erreurs lorsque vous effectuez un redémarrage, votre processus parent ne redémarrera pas et se terminera avec une erreur. Dans le cas d'un redémarrage en douceur (graceful restart), il laissera les processus enfants s'exécuter quand il s'arrêtera. (Ce sont les processus enfants qui "s'arrêtent en douceur" en terminant de traiter leur dernière requête.) Ceci provoquera des problèmes si vous tentez de redémarrer le serveur -- il ne pourra pas s'associer à ses ports d'écoute. Avant d'effectuer un redémarrage, vous pouvez vérifier la syntaxe des fichiers de configuration à l'aide de l'argument de ligne de commande `-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.

## Redémarrer immédiatement

Signal: HUP
  `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é.

Si votre fichier de configuration comporte des erreurs quand vous effectuez un redémarrage, votre processus parent ne redémarrera pas, il se terminera avec une erreur. Voir plus haut la méthode à employer pour éviter ce problème.

## Arrêt en douceur

Signal : WINCH
  `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.

Langues Disponibles: de | en | es | fr | ja | ko | tr