HTTP сервер Apache версии 2.0

Apache > HTTP сервер > Документация > Версия 2.0

# Останов и перезапуск

Доступные языки: de | en | es | ja | ko | ru

This translation may be out of date. Check the English version for recent changes.

Этот документ рассматривает вопросы остановки и перезапуска Apache на Unix-подобных системах. Пользователям Windows NT, 2000 и XP следует читать раздел "Работа Apache как сервиса", а пользователям Windows 9x и ME - "Работа Apache как консольного приложения", для получения информации об управлении сервером на этих платформах.

### См. также

- httpd
- apachectl

## Введение

Для того, чтобы остановить или перезапустить Apache, необходимо послать сигнал запущенным процессам `httpd`. Существует два способа отправить подобные сигналы. Во-первых, Вы можете послать сигналы непосредственно процессам, используя команду unix'а `kill`. Обратите внимание, что процессов `httpd` в системе выполняется несколько, однако Вы не должны отсылать сигналы ни одному из них, кроме родительского - его pid (идентификатор процесса) записывается в файл, путь к которому задается директивой `PidFile`. Существуют три сигнала, которые Вы можете отправить родительскому процессу: `TERM`, `HUP`, и `USR1` - их значение будет объяснено ниже.

Чтобы отправить сигнал родительскому процессу, Вам следует набрать следующую команду:

`kill -TERM `cat /usr/local/apache2/logs/httpd.pid``

Второй способ передать сигналы процессам `httpd` - это использование опции `-k` в командной строке с аргументами: `stop`, `restart` и `graceful`, как будет описано ниже. Это параметры командной строки для исполняемого файла httpd, однако мы рекомендуем передавать их, используя скрипт apachectl, который передаст эти параметры программе `httpd`.

После того, как будут отправлены сигналы процессу `httpd`, вы можете узнать о состоянии сервера, набрав:

`tail -f /usr/local/apache2/logs/error_log`

Внесите необходимые изменения в эти примеры с учётом значения директив `ServerRoot` и `PidFile` в конфигурации Apache.

## Немедленная остановка

Сигнал: TERM
  `apachectl -k stop`

После получения сигнала `TERM` или `stop`, родительский процесс пытается немедленно уничтожить все дочерние процессы. Это может занять несколько секунд. Затем родительский процесс сам завершает работу, при этом все текущие запросы прекращают обрабатываться, а новые запросы игнорируются.

## Мягкий перезапуск

Сигнал: USR1
  `apachectl -k graceful`

При получении сигнала `USR1` или `graceful`, родительский процесс призывает дочерние процессы к завершению работы сразу же после обработки своего текущего запроса (или к незамедлительной остановке, если дочерний процесс ничего не обрабатывает). Родительский процесс перечитывает конфигурационные файлы, открывает заново log-файлы (файлы, содержащие журнал работы сервера). После того, как какой-то из дочерних процессов завершает работу, родительский процесс заменяет его дочерним процессом нового поколения, т.е. с новой конфигурацией, который начинает обрабатывать новые запросы незамедлительно.

На некоторых платформах, не поддерживающих передачу сигнала `USR1` как сигнала для инициации мягкого перезапуска, могут использоваться другие сигналы (такие как `WINCH`). Команда `apachectl graceful` отправит корректный сигнал на любой платформе.

Программа разработана таким образом, что количество процессов и потоков, определённое директивами МП-модуля (мульти-процессного модуля), оставалось неизменным на протяжение всего процесса перезапуска. Кроме того, для поддержания числа запущенных процессов, определённого директивой `StartServers`, используется следующий способ: если спустя одну секунду не было создано по крайней мере такое количество дочерних процессов, какое определено директивой `StartServers`, тогда создаётся такое количество дочерних процессов, которое полностью восполнило бы недостаток. Таким образом сервер пытается одновременно и сохранить количество уже существующих дочерних процессов неизменным, и учесть Ваши требования, указанные в директиве `StartServers`.

Пользователи, использующие модуль `mod_status`, могут обратить внимание, что статистика сервера при получении сигнала `USR1` не обнуляется. Так было сделано для того, чтобы уменьшить промежуток времени, в течение которого сервер не может обрабатывать новые запросы (которые операционная система будет ставить в очередь, т.е. они не пропадут в любом случае), а также для того, чтобы учитывать Ваши настройки. Для этого сервер хранит таблицу статистики, в которую записываются результаты работы всех дочерних процессов, вне зависимости от их поколения.

Модуль `mod_status` также использует символ `G`, чтобы указать те дочерние процессы, которые всё ещё обрабатывают запросы и которые были созданы до сигнала к мягкому перезапуску.

В настоящее время нет способа определить, что все дочерние процессы закончили запись в старый log-файл (т.е. log-файл, в который производилась запись до перезапуска). Мы предлагаем Вам подождать некоторое время, после того как будет послан сигнал `USR1`, прежде чем делать что-либо со старым log-файлом. Например, если на выполнение запросов пользователей, подключённых через очень медленный канал, уходит не более 10 минут, тогда логично будет подождать 15 минут, прежде чем делать что-либо со старым log-файлом.

Если Ваш конфигурационный файл содержит ошибки, то попытка перезапустить сервер вызовет немедленное прекращение работы родительского процесса с сообщением об ошибке. В случае мягкого перезапуска дочерние процессы продолжают обрабатывать свои запросы, после чего они завершат свою работу. Это может вызвать проблемы, так как сервер не будет в состоянии установить соединение с необходимыми портами. Перед выполнением перезапуска, Вы должны проверить синтаксис конфигурационных файлов с помощью параметра `-t` командной строки (см. описание httpd). Однако это всё ещё не гарантирует, что сервер перезапустится корректно. Что проверить семантику конфигурационных файлов, равно как и их синтаксис, Вы можете попробовать запустить `httpd`, будучи непривилегированным пользователем. Если ошибки отсутствуют, то `httpd` попытается открыть сокеты и log-файлы, но не сможет этого сделать, потому что у него отсутствуют необходимые для этого права (или потому что в текущее время работающий `httpd` уже установил соединение с нужными портами, заняв их). Если сбой происходит по любой другой причине - значит, скорее всего, существует ошибка в конфигурационном файле, которая должна быть исправлена перед началом мягкого перезапуска.

## Немедленный перезапуск

Сигнал: HUP
  `apachectl -k restart`

Отправленный родительскому процессу сигнал `HUP` или `restart` вызывает немедленное уничтожение всех дочерних процессов, также как и при обработке сигнала `TERM`, однако родительский процесс не завершает работу. Он перечитывает конфигурационные файлы и открывает заново log-файлы (файлы, содержащие журнал работы сервера). Затем он порождает новых потомков и продолжает обработку запросов.

Пользователи, использующие модуль `mod_status`, могут обратить внимание, что статистика сервера при получении сигнала `HUP` полностью обнуляется.

Если Ваш конфигурационный файл содержит ошибки, то попытка перезапустить сервер вызовет немедленное прекращение его работы с сообщением об ошибке. Способы избежать этого смотрите выше.

## Приложение: сигналы и ситуации гонки (race conditions)

В Apache до версии 1.2b9 существовало несколько ситуаций гонки (race conditions), возникающих при получении сигналов к перезапуску или останову (простое объяснение ситуаций гонки (race conditions): проблема, возникающая, когда что-то происходит в то время, когда не должно происходить, из-за чего нарушается нормальная работа параллельно выполняемых процессов). Для компьютеров с архитектурами, имеющими "правильный", "хороший" набор возможностей, подобные проблемы были устранены везде, где это возможно. Однако следует помнить, что на компьютерах с некоторыми архитектурами всё ещё существует возможность возникновения ситуаций гонки (race conditions).

Компьютеры с архитектурами, на которых таблица статистики хранится в файле, описанном директивой `ScoreBoardFile`, имеют потенциальную возможность повреждения их таблиц статистики. Это может вызвать ошибку "bind: Address already in use" - "установление связи: Адрес уже используется" (после сигнала `HUP`) или "long lost child came home!" - "Возврат потерянного дочернего процесса" (после сигнала `USR1`). Последнее сообщение - фатальная ошибка, в то время как предыдущее вызывает только потерю связи с таблицей статистики. Поэтому можно порекомендовать использовать мягкий перезапуск, и лишь время от времени делать жесткий перезапуск. С этими проблемами очень сложно бороться, однако, к счастью, большинство архитектур не требуют хранить таблицу статистики на диске. Смотрите документацию к директиве `ScoreBoardFile`, чтобы узнать, на каких архитектурах используется этот файл.

Во всех архитектурах существуют небольшие ситуации гонки (race conditions) в каждом дочернем процессе, начиная со второго запроса при постоянном HTTP соединении (KeepAlive). Процесс может завершиться после чтения строки запроса, но перед чтением заголовков запроса. Исправление появилось позже выпуска версии 1.2, а потому не включено в него. Теоретически, это не проблема, потому что KeepAlive-клиент должен ожидать таких событий из-за задержек сети и времени ожидания сервера. Практически, складывается впечатление, что это также не оказывает никакого влияния - во время тестов сервер перезапускался с частотой 20 раз в секунду, а клиенты успешно просматривали сайт, не получая пустых документов и повреждённых картинок.

Доступные языки: de | en | es | ja | ko | ru