Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://uneex.mithril.cs.msu.su/static/Apache_2.0_Doc/stopping.html
Дата изменения: Mon Sep 26 12:35:52 2011 Дата индексирования: Mon Oct 1 23:22:59 2012 Кодировка: koi8-r |
HTTP сервер Apache версии 2.0
Этот документ рассматривает вопросы остановки и перезапуска Apache на Unix-подобных системах. Пользователям Windows NT, 2000 и XP следует читать раздел "Работа Apache как сервиса", а пользователям Windows 9x и ME - "Работа Apache как консольного приложения", для получения информации об управлении сервером на этих платформах.
Для того, чтобы остановить или перезапустить 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.
apachectl -k stop
После получения сигнала TERM
или stop
,
родительский процесс пытается немедленно уничтожить все дочерние процессы.
Это может занять несколько секунд. Затем родительский процесс сам завершает работу,
при этом все текущие запросы прекращают обрабатываться, а новые запросы игнорируются.
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
уже
установил соединение с нужными портами, заняв их). Если сбой
происходит по любой другой причине - значит, скорее всего,
существует ошибка в конфигурационном файле, которая должна быть
исправлена перед началом мягкого перезапуска.apachectl -k restart
Отправленный родительскому процессу сигнал HUP
или restart
вызывает немедленное уничтожение
всех дочерних процессов, также как и при обработке сигнала
TERM
, однако родительский процесс не завершает работу.
Он перечитывает конфигурационные файлы и открывает заново log-файлы
(файлы, содержащие журнал работы сервера). Затем он порождает
новых потомков и продолжает обработку запросов.
Пользователи, использующие модуль mod_status
,
могут обратить внимание, что статистика сервера при получении сигнала
HUP
полностью обнуляется.
В Apache до версии 1.2b9 существовало несколько ситуаций гонки, возникающих при получении сигналов к перезапуску или останову (проще говоря, ситуация гонки - чувствительная ко времени проблема, возникающая, когда что-то происходит в неподходящее время или в неправильном порядке. Если то же самое происходит в подходящее время, никаких проблем не возникает). Для компьютеров с архитектурами, имеющими "правильный", "хороший" набор возможностей, подобные проблемы были устранены везде, где это возможно. Однако следует помнить, что на компьютерах с некоторыми архитектурами всё ещё существует возможность возникновения ситуаций гонки.
Компьютеры с архитектурами, на которых таблица статистики хранится
в файле, заданном директивой ScoreBoardFile
,
имеют потенциальную возможность повреждения их таблиц статистики.
Это может вызвать ошибку "bind: Address already in use"
(после сигнала HUP
)
или "long lost child came home!"
(после сигнала USR1
). Последнее сообщение - фатальная ошибка,
в то время как предыдущее сигнализирует только о потере связи с таблицей статистики.
Поэтому можно порекомендовать использовать мягкий перезапуск, и лишь время от времени
делать жесткий перезапуск. С этими проблемами очень сложно бороться,
однако, к счастью, большинство архитектур не требуют хранить таблицу статистики
на диске. Смотрите документацию к директиве ScoreBoardFile
, чтобы узнать, на каких архитектурах
используется этот файл.
Во всех архитектурах существуют небольшие ситуации гонки в каждом дочернем процессе, начиная со второго запроса при постоянном HTTP соединении (KeepAlive). Процесс может завершиться после чтения строки запроса, но перед чтением заголовков запроса. Исправление появилось позже выпуска версии 1.2, а потому не включено в него. Теоретически это не проблема, потому что KeepAlive-клиент должен ожидать таких событий из-за задержек сети и времени ожидания сервера. Практически складывается впечатление, что это также не оказывает никакого влияния - во время тестов сервер перезапускался с частотой 20 раз в секунду, а клиенты успешно просматривали сайт, не получая пустых документов и повреждённых картинок.