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

Введение

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

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

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

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

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

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

Сигнал: TERM

apachectl -k stop

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

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

Сигнал: USR1

apachectl -k graceful

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

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

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

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

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

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

Сигнал: 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 раз в секунду, а клиенты успешно просматривали сайт, не получая пустых документов и повреждённых картинок.