Я использую 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
Он выполнит горячую перезагрузку конфигурации без простоя. Если у вас есть ожидающие запросы, тогда будут существовать процессы nginx, которые будут обрабатывать эти соединения до того, как они умрут, так что это чрезвычайно изящный способ перезагрузки конфигураций.
Иногда вы можете добавить в начало sudo
Бегать /usr/sbin/nginx -s reload
Видеть http://wiki.nginx.org/CommandLine для получения дополнительных параметров командной строки.
Нет, вы ошибаетесь, вы не должны столкнуться с простоями из-за описанной вами процедуры. (Nginx может не только перезагружать конфигурацию "на лету" без простоев, но и обновлять исполняемый файл "на лету" без простоев.)
Согласно http://nginx.org/docs/control.html#reconfiguration, отправив HUP signal для nginx гарантирует, что он выполнит плавный перезапуск, и, если файлы конфигурации неверны, вся процедура будет прекращена, и вы останетесь с nginx, как и перед отправкой HUP сигнал. Ни в коем случае не должно быть простоев.
Чтобы nginx перечитал файл конфигурации, в главный процесс должен быть отправлен сигнал HUP. Главный процесс сначала проверяет допустимость синтаксиса, затем пытается применить новую конфигурацию, то есть открыть файлы журнала и новые прослушивающие сокеты. Если это не удается, он откатывает изменения и продолжает работать со старой конфигурацией.
Для полноты картины systemd способ сделать это:
systemctl reload nginx
Обычно перезагрузка файла конфигурации службы не должна влиять на работающую службу. Однако это зависит от того, как SIGHUP сигнал обрабатывается.
Если во время перезагрузки какой-то службы происходит простой, этого можно избежать, запустив одну и ту же службу на нескольких серверах, предпочтительно с использованием балансировщика нагрузки. В этом случае вы можете снимать по одному серверу за раз и перезагружать / перезапускать его. Затем его можно будет добавить повторно, убедившись, что все в порядке.
В kill подход, который вы использовали (kill -s HUP $(cat /var/run/nginx.pid) правильно. Сценарии инициализации для дистрибутивов RH или Debian в конечном итоге также реализованы с использованием kill команда. Вы можете проверить Пример инициализации с сайта nginx или содержание Пакет Ubuntu Nginx.
Есть несколько сигналов, которые nginx может прослушивать (упоминается в вики):
TERM, INT - Быстрое отключение.QUIT - Изящное выключение.KILL - Останавливает упорный процесс.HUP - Перезагрузка конфигурации. Запустите новые рабочие процессы с новой конфигурацией. Изящно завершите работу старых рабочих процессов.USR1 - Снова откройте файлы журнала.USR2 - Обновите исполняемый файл на лету.WINCH - Изящно завершите рабочие процессы.Nginx перезагрузка (HUP signal) более конкретно реализован в виде нескольких шагов [1,2]:
Я могу придумать только одну проблему, почему у вас был простой (на основе процесса перезагрузки), что вы использовали только один рабочий процесс (worker_processes директива), которая по замыслу обслуживала старых клиентов, но имела закрытый прослушивающий сокет, поэтому вы не могли открыть новое соединение.
Я также могу порекомендовать вам всегда использовать /usr/sbin/nginx -t для проверки файлов конфигурации перед применением новой конфигурации.
Сигнал реконфигурации обрабатывается в файле ngx_process_cycle.c и мы видим, что он запускает новые рабочие процессы в функции ngx_start_worker_processes(...) и в конце он останавливает старые рабочие процессы в работе ngx_signal_worker_processes(...), который перебирает их с участием NGX_SHUTDOWN_SIGNAL сигнал.
Ресурсы: