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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1" /><!-- Traduction anglais 1.18 -->
<title>Arrêt et redémarrage d'Apache</title>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
vlink="#000080" alink="#FF0000">
<div align="CENTER">
<img src="images/sub.gif" alt="[APACHE DOCUMENTATION]" />
<h3>Apache HTTP Server</h3>
</div>
<h1 align="CENTER">Arrêt et redémarrage
d'Apache</h1>
<p>Ce document décrit l'arrêt et le
redémarrage d'Apache sur Unix et Cygwin seulement. Les
utilisateurs de Windows sont invités à lire le
paragraphe <a href="windows.html#signal">signaler à
Apache en cours d'exécution</a>.</p>
<p>Lorsque qu'Apache s'exécute, vous pouvez noter que
plusieurs processus <code>httpd</code> s'exécutent en
même temps sur votre machine, mais vous ne devez envoyer
de signaux qu'à celui dont l'identifiant de processus
est celui contenu dans le fichier <a
href="mod/core.html#pidfile">PidFile</a>. Autrement dit, vous
ne devez jamais envoyer de signaux aux processus
<code>httpd</code> autres que le processus père. Il
existe trois signaux que vous pouvez envoyer au processus
père : <code>TERM</code>, <code>HUP</code>, et
<code>USR1</code>, dont la signification est décrite ci
dessous.</p>
<p>Pour envoyer un signal au père vous pouvez utiliser
une commande comme</p>
<blockquote>
<pre>
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
</pre>
</blockquote>
Vous pouvez lire l'effet de la commande
précédente en effectuant la commande
<blockquote>
<pre>
tail -f /usr/local/apache/logs/error_log
</pre>
</blockquote>
Ces exemples devront être modifiés en fonction des
valeurs des directives <a
href="mod/core.html#serverroot">ServerRoot</a> et <a
href="mod/core.html#pidfile">PidFile</a>.
<p>Avec Apache 1.3 est fourni un script <a
href="programs/apachectl.html">apachectl</a> 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.</p>
<h3>Signal TERM : arrêt immédiat</h3>
<p>L'envoi du signal <code>TERM</code> demande au processus
père d'essayer de tuer tous ses processus fils. Il peut
s'écouler 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.</p>
<h3>Signal HUP : redémarrage immédiat</h3>
<p>L'envoi du signal <code>HUP</code> demande au processus
père de tuer tous ses processus fils, comme le signal
<code>TERM</code>, 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 nouvel ensemble de
processus fils et continue de traiter les requêtes.</p>
<p>Les utilisateurs du module <a
href="mod/mod_status.html">status</a> noteront que les
statistiques du serveur sont réinitialisées
à zéro après l'envoi du signal
<code>HUP</code>.</p>
<p><strong>Note:</strong> 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 permettant d'éviter ce
problème.</p>
<h3>Signal USR1 : redémarrage en douceur</h3>
<p><strong>Note:</strong> pour les versions inférieures
à 1.2b9 cette fonction est instable et ne doit pas
être utilisée.</p>
<p>Le signal <code>USR1</code> 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 s'ils n'ont pas de traitement 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 des processus fils
prenant en compte la nouvelle <em>génération</em>
de la configuration, et commencent aussitôt à
traiter les nouvelles requêtes.</p>
<p>Cette fonction est conçue pour toujours respecter les
valeurs de <a href="mod/core.html#maxclients">MaxClients</a>,
<a href="mod/core.html#minspareservers">MinSpareServers</a>, et
<a href="mod/core.html#maxspareservers">MaxSpareServers</a>. De
plus, elle respecte la valeur de <a
href="mod/core.html#startservers">StartServers</a> 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.</p>
<p>Les utilisateurs du module <a
href="mod/mod_status.html">status</a> noteront que les
statistiques du serveur <strong>ne sont pas</strong>
réinitialisées à zéro après
l'envoi du signal <code>USR1</code>. 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
<em>table de comunication interprocessus</em> pour les
différents processus fils et leur
génération.</p>
<p>Le module <a href="mod/mod_status.html">status</a> utilise
également un <code>G</code> pour marquer les fils
traitant les requêtes démarrées avant le
redémarrage en douceur.</p>
<p>Actuellement, il n'y a aucun moyen pour un script de
rotation des fichiers de trace qui utiliserait le signal
<code>USR1</code> 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 soit 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 devrez attendre quinze minutes avant de faire
quelque chose avec l'ancien fichier de trace.</p>
<p><strong>Note:</strong> Si votre fichier de configuration
contient des erreurs au moment de réinitialiser le
processus père, ce dernier 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 <code>-t</code> (cf. <a
href="programs/httpd.html">httpd</a>). 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 <code>httpd</code> sous un compte utilisateur autre que
root. S'il n'y a pas d'erreur, il essaiera d'ouvrir ses ports
réseau, mais échouera, soit parce qu'il n'est pas
root, soit parce que le serveur existant est déjà
connecté sur ces ports. S'il échoue pour une
autre raison, c'est qu'il existe une erreur dans les fichiers
de configuration et cette erreur doit être
corrigée avant de déclencher une relance en
douceur.</p>
<h3>Annexe : signaux et conditions temporelles</h3>
<p>Avant la version 1.2b9 d'Apache il existait un certain
nombre de <em>conditions temporelles</em> 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.</p>
<p>Les architectures utilisant un fichier sur disque <a
href="mod/core.html#scoreboardfile">ScoreBoardFile</a> 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
<code>HUP</code>) ou "long lost child came home!" (après
le signal <code>USR1</code>). Le premier est une erreur fatale,
tandis que le 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émarrages
immédiats. Ces problèmes sont très
difficiles à éviter, mais heureusement de
nombreuses architectures n'ont pas besoin d'utiliser un fichier
pour la communication interprocessus. Consulter la
documentation sur <a
href="mod/core.html#scoreboardfile">ScoreBoardFile</a> pour
savoir si votre architecture l'utilise.</p>
<p><code>NEXT</code> et <code>MACHTEN</code> (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ème majeur.</p>
<p>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 connexions doit être capable
de traiter ce genre de cas, qui peut se produire soit à
cause des temps de latence du réseau, soit à
cause des délais de réponse trop longs 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 consulter le site sans obtenir de documents vides ou
d'images invalides.</p>
<hr />
<h3 align="CENTER">Apache HTTP Server</h3>
<a href="./"><img src="images/index.gif" alt="Index" /></a>
</body>
</html>
|
