Nginx конфигурируют перезагрузку без времени простоя

Вы проверили, что окна считают, Вы связались с сервисом SQLAgent, имеет "вход в систему как сервис" свойства в примененной групповой политике (активный домен каталога)?

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

123
задан 11 April 2012 в 20:13
6 ответов

Запустите service nginx reload или /etc/init.d/nginx reload

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

Иногда вы можете добавить sudo

182
ответ дан 28 November 2019 в 19:19

Для полноты, systemd способ сделать его:

systemctl reload nginx
0
ответ дан 28 November 2019 в 19:19

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

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

2
ответ дан 28 November 2019 в 19:19

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

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

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

9
ответ дан 28 November 2019 в 19:19

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

Дополнительные параметры командной строки см. http://wiki.nginx.org/CommandLine .

81
ответ дан 28 November 2019 в 19:19

Nginx и сигналы

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

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

  • TERM, INT— Быстрое завершение работы.
  • ВЫХОД— Мягкое завершение работы.
  • 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.

Ресурсы:

8
ответ дан 29 May 2020 в 02:32

Теги

Похожие вопросы