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

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

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

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

Этот документ рассматривает вопросы остановки и перезапуска 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 существовало несколько ситуаций гонки, возникающих при получении сигналов к перезапуску или останову (проще говоря, ситуация гонки - чувствительная ко времени проблема, возникающая, когда что-то происходит в неподходящее время или в неправильном порядке. Если то же самое происходит в подходящее время, никаких проблем не возникает). Для компьютеров с архитектурами, имеющими "правильный", "хороший" набор возможностей, подобные проблемы были устранены везде, где это возможно. Однако следует помнить, что на компьютерах с некоторыми архитектурами всё ещё существует возможность возникновения ситуаций гонки.

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

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

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