1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- LastChangedRevision English document : 420990 -->
<!-- French translation : Lucien GENTIS -->
<!-- $LastChangedRevision: 2007070101 $ -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="stopping.xml.meta">
<title>Arrêt et redémarrage</title>
<summary>
<p>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
<a href="platform/windows.html#winsvc">Exécuter Apache en tant que
service</a> et les utilisateurs de Windows 9x et ME doivent consulter
<a href="platform/windows.html#wincons">Exécuter Apache comme une
application de type console</a> pour plus d'informations sur le contrôle
d'Apache à partir de ces plateformes.</p>
</summary>
<seealso><program>httpd</program></seealso>
<seealso><program>apachectl</program></seealso>
<seealso><a href="invoking.html">Démarrage</a></seealso>
<section id="introduction"><title>Introduction</title>
<p>Afin d'arrêter ou redémarrer Apache, vous devez envoyer un signal aux
processus <program>httpd</program> en cours d'exécution. Les signaux
peuvent être envoyés de deux manières. Tout d'abord, vous pouvez
utiliser la commande unix <code>kill</code>
pour envoyer directement des signaux aux processus. Vous pouvez remarquer
que plusieurs processus <program>httpd</program> 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
<directive module="mpm_common">PidFile</directive>. 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 :
<code><a href="#term">TERM</a></code>,
<code><a href="#graceful">USR1</a></code>,
<code><a href="#hup">HUP</a></code>, et
<code><a href="#gracefulstop">WINCH</a></code>, qui
sera décrit plus loin.</p>
<p>Pour envoyer un signal au processus parent, vous devez entrer une commande
du style :</p>
<example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example>
<p>La seconde méthode permettant d'envoyer des signaux aux processus
<program>httpd</program>
consiste à utiliser les options de ligne de commande <code>-k</code> :
<code>stop</code>,
<code>restart</code>, <code>graceful</code> et <code>graceful-stop</code>,
comme décrit ci-dessous. Ce sont des arguments du binaire
<program> httpd</program>, mais il est recommandé de les utiliser
avec le script de contrôle <program>apachectl</program>, qui se
chargera de les passer à <program>httpd</program>.</p>
<p>Après avoir envoyé un signal à <program>httpd</program>, vous pouvez
suivre le cours de son action en entrant :</p>
<example>tail -f /usr/local/apache2/logs/error_log</example>
<p>Adaptez ces exemples en fonction de la définition de vos directives
<directive module="core">ServerRoot</directive> et
<directive module="mpm_common">PidFile</directive>.</p>
</section>
<section id="term"><title>Arrêter immédiatement</title>
<dl><dt>Signal: TERM</dt>
<dd><code>apachectl -k stop</code></dd>
</dl>
<p>L'envoi du signal <code>TERM</code> ou <code>stop</code> 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.</p>
</section>
<section id="graceful"><title>Redémarrage en douceur</title>
<dl><dt>Signal: USR1</dt>
<dd><code>apachectl -k graceful</code></dd>
</dl>
<p>L'envoi du signal <code>USR1</code> ou <code>graceful</code> au
processus parent lui fait envoyer aux processus enfants
<em>l'ordre</em> 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 <em>génération</em> de la
configuration, et celui-ci commence immédiatement à traiter les
nouvelles requêtes.</p>
<p>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
<directive module="mpm_common">StartServers</directive> de la manière
suivante : si après une seconde au moins <directive
module="mpm_common">StartServers</directive> 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 <directive module="mpm_common">StartServers</directive>.</p>
<p>Les utilisateurs du module <module>mod_status</module>
noteront que les statistiques du serveur ne sont <strong>pas</strong>
remises à zéro quand un signal <code>USR1</code> 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
<em>tableau</em> utilisé pour garder la trace de tous les processus
enfants au cours des différentes générations.</p>
<p>Le module status utilise aussi un <code>G</code> 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é.</p>
<p>Pour l'instant, il est impossible pour un script de rotation
des logs utilisant
<code>USR1</code> 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 <code>USR1</code>
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.</p>
<note>
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 <code>-t</code>
(voir <program>httpd</program>).
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
<program>httpd</program> 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
<program>httpd</program> 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.</note>
</section>
<section id="hup"><title>Redémarrer immédiatement</title>
<dl><dt>Signal: HUP</dt>
<dd><code>apachectl -k restart</code></dd>
</dl>
<p>L'envoi du signal <code>HUP</code> ou <code>restart</code> au
processus parent lui fait tuer ses processus enfants comme pour le signal
<code>TERM</code>, 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.</p>
<p>Les utilisateurs du module <module>mod_status</module>
noteront que les statistiques du serveur sont remises à zéro quand un
signal <code>HUP</code> est envoyé.</p>
<note>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.</note>
</section>
<section id="gracefulstop"><title>Arrêt en douceur</title>
<dl><dt>Signal : WINCH</dt>
<dd><code>apachectl -k graceful-stop</code></dd>
</dl>
<p>L'envoi du signal <code>WINCH</code> ou <code>graceful-stop</code>
au processus parent lui fait <em>aviser</em> 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
<directive module="mpm_common">PidFile</directive> 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 <directive
module="mpm_common">GracefulShutdownTimeout</directive> 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 <code>TERM</code>
afin de le forcer à s'arrêter.</p>
<p>L'envoi du signal <code>TERM</code> va arrêter immédiatement
les processus parent et enfants en état "graceful". Cependant,
comme le fichier <directive module="mpm_common">PidFile</directive>
aura été supprimé, vous ne pourrez pas utiliser
<code>apachectl</code> ou <code>httpd</code> pour envoyer ce signal.</p>
<note><p>Le signal <code>graceful-stop</code> vous permet d'exécuter
simultanément plusieurs instances de <program>httpd</program>
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.</p>
<p>On a pris soin de s'assurer que les fichiers sur disque
comme ceux définis par les directives
<directive module="core">Lockfile</directive> et
<directive module="mod_cgid">ScriptSock</directive> 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 <program>httpd</program> qui s'exécute
n'écrase pas les fichiers des autres instances.</p>
<p>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 <program>rotation des logs</program>. Plusieurs instances
du programme de <program>rotation des logs</program> 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.</p></note>
</section>
</manualpage>
|
