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
|
<?xml version='1.0' encoding='KOI8-R' ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ru.xsl"?>
<!-- English Revision: 421174:586785 (outdated) -->
<!--
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.
-->
<!--***************************************************-->
<!-- Translator: Mikhail Filimonov (mvf@uniyar.ac.ru) -->
<!-- Reviewers: -->
<!-- Ivan Shvedov (ivan@tversu.ru) -->
<!-- Arthur Reznikov (art@altair.tversu.ru)-->
<!--***************************************************-->
<manualpage metafile="stopping.xml.meta">
<title>Останов и перезапуск</title>
<summary>
<p>Этот документ рассматривает вопросы остановки и перезапуска Apache на
Unix-подобных системах. Пользователям Windows NT, 2000 и XP следует читать раздел
<a href="platform/windows.html#winsvc">"Работа Apache как сервиса"</a>,
а пользователям Windows 9x и ME - <a href="platform/windows.html#wincons">"Работа
Apache как консольного приложения"</a>, для получения информации об
управлении сервером на этих платформах.</p>
</summary>
<seealso><program>httpd</program></seealso>
<seealso><program>apachectl</program></seealso>
<section id="introduction"><title>Введение</title>
<p>Для того, чтобы остановить или перезапустить Apache, необходимо послать
сигнал запущенным процессам <program>httpd</program>. Существует два способа
отправить подобные сигналы. Во-первых, вы можете послать сигналы непосредственно
процессам, используя команду unix <code>kill</code>. Обратите внимание,
что процессов <program>httpd</program> в системе выполняется несколько,
однако вы не должны отсылать сигналы ни одному из них, кроме родительского -
его pid (идентификатор процесса) записывается в файл, путь к которому задается
директивой <directive module="mpm_common">PidFile</directive>. Существуют три
сигнала, которые вы можете отправить родительскому процессу:
<a href="#term"><code>TERM</code></a>,
<a href="#hup"><code>HUP</code></a>, и
<a href="#graceful"><code>USR1</code></a> - их значение будет объяснено ниже.</p>
<p>Чтобы отправить сигнал родительскому процессу, вам следует набрать следующую команду:</p>
<example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example>
<p>Второй способ передать сигналы процессам <program>httpd</program> - это
использование опции <code>-k</code> в командной строке с аргументами: <code>stop</code>,
<code>restart</code> и <code>graceful</code>, как будет описано ниже.
Это параметры командной строки для исполняемого файла <program>httpd</program>,
однако мы рекомендуем передавать их, используя скрипт <program>apachectl</program>,
который передаст эти параметры программе <program>httpd</program>.</p>
<p>После того, как будут отправлены сигналы процессу <code>httpd</code>, вы можете
узнать о состоянии сервера, набрав:</p>
<example>tail -f /usr/local/apache2/logs/error_log</example>
<p>Внесите необходимые изменения в эти примеры с учётом
значения директив <directive module="core">ServerRoot</directive>
и <directive module="mpm_common">PidFile</directive> в конфигурации
Apache.</p>
</section>
<section id="term"><title>Немедленная остановка</title>
<dl><dt>Сигнал: TERM</dt>
<dd><code>apachectl -k stop</code></dd>
</dl>
<p>После получения сигнала <code>TERM</code> или <code>stop</code>,
родительский процесс пытается немедленно уничтожить все дочерние процессы.
Это может занять несколько секунд. Затем родительский процесс сам завершает работу,
при этом все текущие запросы прекращают обрабатываться, а новые запросы игнорируются.</p>
</section>
<section id="graceful"><title>Мягкий перезапуск</title>
<dl><dt>Сигнал: USR1</dt>
<dd><code>apachectl -k graceful</code></dd>
</dl>
<p>При получении сигнала <code>USR1</code> или <code>graceful</code>,
родительский процесс <em>призывает</em> дочерние процессы к завершению работы
сразу же после обработки своего текущего запроса (или к незамедлительной остановке,
если дочерний процесс ничего не обрабатывает). Родительский процесс
перечитывает конфигурационные файлы, открывает заново log-файлы
(файлы, содержащие журнал работы сервера). После того, как какой-то из
дочерних процессов завершает работу, родительский процесс заменяет его
дочерним процессом нового <em>поколения</em>, т.е. с новой конфигурацией,
который начинает обрабатывать новые запросы незамедлительно.</p>
<note>На некоторых платформах, не поддерживающих передачу сигнала <code>USR1</code>
как сигнала для инициации мягкого перезапуска, могут
использоваться другие сигналы (такие как <code>WINCH</code>).
Команда <code>apachectl graceful</code> отправит корректный сигнал
на любой платформе.</note>
<p>Программа разработана таким образом, что количество процессов и потоков,
определённое директивами МП-модуля (мульти-процессного модуля),
оставалось неизменным на протяжение всего процесса перезапуска.
Кроме того, для поддержания числа запущенных процессов, определённого
директивой <directive module="mpm_common">StartServers</directive>,
используется следующий способ: если спустя одну секунду не было
создано по крайней мере такое количество дочерних процессов, какое
определено директивой <directive module="mpm_common">StartServers</directive>,
тогда создаётся такое количество дочерних процессов, которое полностью
восполнило бы недостаток. Таким образом сервер пытается одновременно и сохранить
количество уже существующих дочерних процессов неизменным, и учесть ваши
требования, указанные в директиве <directive
module="mpm_common">StartServers</directive>.</p>
<p>Пользователи, использующие модуль <module>mod_status</module>,
могут обратить внимание, что статистика сервера при получении сигнала
<code>USR1</code> не обнуляется. Так было сделано для того, чтобы уменьшить
промежуток времени, в течение которого сервер не может обрабатывать
новые запросы (которые операционная система будет ставить в очередь,
т.е. они не пропадут в любом случае), а также для того, чтобы учитывать
ваши настройки. Для этого сервер хранит <em>таблицу статистики</em>,
в которую записываются результаты работы всех дочерних процессов, вне зависимости от их поколения.</p>
<p>Модуль <code>mod_status</code> также использует символ <code>G</code>, чтобы
обозначить те дочерние процессы, которые всё ещё обрабатывают запросы и которые были
созданы до сигнала к мягкому перезапуску.</p>
<p>В настоящее время нет способа определить,
что все дочерние процессы закончили запись в старый log-файл (т.е.
log-файл, в который производилась запись до перезапуска). Мы
предлагаем вам подождать некоторое время, после того как будет
послан сигнал <code>USR1</code>, прежде чем делать что-либо
со старым log-файлом. Например, если на выполнение запросов
пользователей, подключённых через очень медленный канал, уходит
не более 10 минут, тогда логично будет подождать 15 минут, прежде чем
делать что-либо со старым log-файлом.</p>
<note>Если Ваш конфигурационный файл содержит ошибки, то попытка
перезапустить сервер вызовет немедленное прекращение работы родительского
процесса с сообщением об ошибке. В случае мягкого перезапуска
дочерние процессы продолжают обрабатывать свои запросы, после чего
они завершат свою работу. Это может вызвать проблемы,
так как сервер не будет в состоянии установить соединение с необходимыми
портами. Перед выполнением перезапуска, вы должны
проверить синтаксис конфигурационных файлов с помощью параметра
<code>-t</code> командной строки (см. описание <program>httpd</program>).
Однако это всё ещё не гарантирует, что сервер перезапустится корректно.
Чтобы проверить семантику конфигурационных файлов, равно как и их синтаксис,
вы можете попробовать запустить <program>httpd</program>, будучи непривилегированным пользователем.
Если ошибки отсутствуют, то <program>httpd</program> попытается открыть
сокеты и log-файлы, но не сможет этого сделать, потому что у него отсутствуют
необходимые для этого права (или потому что в текущее время работающий <program>httpd</program> уже
установил соединение с нужными портами, заняв их). Если сбой
происходит по любой другой причине - значит, скорее всего,
существует ошибка в конфигурационном файле, которая должна быть
исправлена перед началом мягкого перезапуска.</note>
</section>
<section id="hup"><title>Немедленный перезапуск</title>
<dl><dt>Сигнал: HUP</dt>
<dd><code>apachectl -k restart</code></dd>
</dl>
<p>Отправленный родительскому процессу сигнал <code>HUP</code>
или <code>restart</code> вызывает немедленное уничтожение
всех дочерних процессов, также как и при обработке сигнала
<code>TERM</code>, однако родительский процесс не завершает работу.
Он перечитывает конфигурационные файлы и открывает заново log-файлы
(файлы, содержащие журнал работы сервера). Затем он порождает
новых потомков и продолжает обработку запросов.</p>
<p>Пользователи, использующие модуль <module>mod_status</module>,
могут обратить внимание, что статистика сервера при получении сигнала
<code>HUP</code> полностью обнуляется.</p>
<note>Если Ваш конфигурационный файл содержит ошибки, то попытка
перезапустить сервер вызовет немедленное прекращение его работы
с сообщением об ошибке. Способы избежать этого смотрите выше.
</note>
</section>
<section id="race"><title>Приложение: сигналы и ситуации гонки (race conditions)</title>
<p>В Apache до версии 1.2b9 существовало несколько <em>ситуаций гонки</em>,
возникающих при получении сигналов к перезапуску или останову
(проще говоря, ситуация гонки - чувствительная ко времени проблема,
возникающая,
когда что-то происходит в неподходящее время или в неправильном порядке.
Если то же самое происходит в подходящее время, никаких проблем не возникает).
Для компьютеров с архитектурами, имеющими "правильный", "хороший" набор
возможностей, подобные проблемы были устранены везде, где это возможно.
Однако следует помнить, что на компьютерах с некоторыми архитектурами
всё ещё существует возможность возникновения ситуаций гонки.</p>
<p>Компьютеры с архитектурами, на которых таблица статистики хранится
в файле, заданном директивой <directive module="mpm_common">ScoreBoardFile</directive>,
имеют потенциальную возможность повреждения их таблиц статистики.
Это может вызвать ошибку "bind: Address already in use"
(после сигнала <code>HUP</code>)
или "long lost child came home!"
(после сигнала <code>USR1</code>). Последнее сообщение - фатальная ошибка,
в то время как предыдущее сигнализирует только о потере связи с таблицей статистики.
Поэтому можно порекомендовать использовать мягкий перезапуск, и лишь время от времени
делать жесткий перезапуск. С этими проблемами очень сложно бороться,
однако, к счастью, большинство архитектур не требуют хранить таблицу статистики
на диске. Смотрите документацию к директиве <directive
module="mpm_common">ScoreBoardFile</directive>, чтобы узнать, на каких архитектурах
используется этот файл.</p>
<p>Во всех архитектурах существуют небольшие ситуации гонки
в каждом дочернем процессе, начиная со второго запроса при постоянном
HTTP соединении (KeepAlive). Процесс может завершиться после чтения
строки запроса, но перед чтением заголовков запроса. Исправление
появилось позже выпуска версии 1.2, а потому не включено в него. Теоретически это
не проблема, потому что KeepAlive-клиент должен ожидать таких событий
из-за задержек сети и времени ожидания сервера. Практически
складывается впечатление, что это также не оказывает никакого
влияния - во время тестов сервер перезапускался с частотой 20 раз
в секунду, а клиенты успешно просматривали сайт, не получая
пустых документов и повреждённых картинок.</p>
</section>
</manualpage>
|
