Перезагрузка конфигурации Nginx без остановки работы

Я использую nginx как обратный прокси. Каждый раз, когда я обновляю конфигурацию с помощью

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/nginx.pid`"

Я сталкиваюсь с кратковременным простоем. Как я могу этого избежать?

Запустите service nginx reload, /etc/init.d/nginx reload, /usr/sbin/nginx -s reload или /usr/sbin/nginx reload

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

Иногда вам может понадобиться предварить команду sudo

Запустите /usr/sbin/nginx -s reload

Смотрите http://wiki.nginx.org/CommandLine для получения дополнительных параметров командной строки.

Nginx и сигналы

Использованный вами подход с kill (kill -s HUP $(cat /var/run/nginx.pid) является правильным. Инициализационные скрипты для дистрибутивов RH или Debian в конечном итоге также реализованы с помощью команды kill. Вы можете проверить пример инициализации с сайта nginx или содержимое пакета Nginx для Ubuntu.

Существует несколько сигналов, на которые nginx может реагировать (упомянуто в вики):

• TERM, INT – Быстрое отключение.
• QUIT – Мягкое отключение.
• KILL – Останавливает упрямый процесс.
• HUP – Перезагрузка конфигурации. Запускает новые рабочие процессы с новой конфигурацией. Мягко завершает старые рабочие процессы.
• USR1 – Повторное открытие лог-файлов.
• USR2 – Обновление исполняемого файла на лету.
• WINCH – Мягкое отключение рабочих процессов.

Перезагрузка Nginx

Перезагрузка Nginx (сигнал HUP) реализована более специфично в несколько этапов [1,2]:

• Мастеровый процесс проверяет синтаксическую корректность.
• Применяет новую конфигурацию, т.е. открывает лог-файлы и новые сокеты для прослушивания.
• Если это не удается, он отменяет изменения и продолжает работать со старой конфигурацией.
• Если это удается, он запускает новые рабочие процессы и отправляет сообщения старым рабочим процессам с просьбой мягко завершить работу.
• Старые рабочие процессы закрывают сокеты для прослушивания и продолжают обслуживать старых клиентов.
• После того как все клиенты обслужены, старые рабочие процессы завершаются.

Единственная причина, по которой, как я могу предположить, у вас был простой (на основе процесса перезагрузки), это то, что вы использовали только один рабочий процесс (worker_processes директива), который по дизайну обслуживал старых клиентов, но закрыл сокет для прослушивания, поэтому вы не могли открыть новое соединение.

Я также рекомендую вам всегда использовать /usr/sbin/nginx -t для проверки конфигурационных файлов перед применением новой конфигурации.

Глубокая перезагрузка Nginx

Сигнал перенастройки обрабатывается в файле ngx_process_cycle.c, и мы можем увидеть, как он запускает новые рабочие процессы в функции ngx_start_worker_processes(...), а в конце останавливает старые рабочие процессы в функции ngx_signal_worker_processes(...), которая перебирает их с сигналом NGX_SHUTDOWN_SIGNAL.

Ресурсы:

• [1] https://nginx.org/en/docs/control.html
• [2] https://www.nginx.com/resources/wiki/start/topics/tutorials/commandline/#stopping-or-restarting-nginx

Для полноты картины, способ с systemd:

systemctl reload nginx

Нет, вы неправы, вы не должны сталкиваться с простоями при выполнении описанной вами процедуры. (Nginx может выполнять не только перезагрузку конфигурации на лету без простоя, но даже обновление исполняемого файла на лету, все еще без простоя.)

Согласно http://nginx.org/docs/control.html#reconfiguration, отправка сигнала HUP в nginx гарантирует его мягкое перезапускание, и, если конфигурационные файлы неправильные, вся процедура отменяется, и вы получаете nginx в том состоянии, в котором он был до отправки сигнала HUP. Ни в какой момент не следует ожидать простоя.

Для того чтобы nginx повторно прочитал конфигурационный файл, сигнал HUP должен быть отправлен мастеровому процессу. Сначала мастеровый процесс проверяет синтаксическую корректность, затем пытается применить новую конфигурацию, т.е. открывает лог-файлы и новые сокеты для прослушивания. Если это не удается, он отменяет изменения и продолжает работать со старой конфигурацией.

Обычно перезагрузка конфигурационного файла сервиса не должна влиять на работающий сервис. Однако это зависит от того, как обрабатывается сигнал SIGHUP.

Если конкретный сервис испытывает простой во время перезагрузки, это можно обойти, запустив тот же сервис на нескольких серверах, желательно с использованием балансировщика нагрузки. В этом случае вы можете отключить один сервер за один раз и перезагрузить/перезапустить его. Затем его можно снова подключить после подтверждения его работоспособности.

Во-первых, вы уверены, что конфигурация верна. Вам следует проверить конфигурацию в nginx.conf. Вы можете использовать команду ниже для проверки.

nginx -t

После этого, если конфигурация верна, вы можете перезагрузить nginx. Если она неверна, сначала отредактируйте вашу конфигурацию, а затем снова проверьте, используя nginx -t и перезагрузите nginx.

Вы можете использовать команду ниже.

systemctl reload nginx