RuCommandLine

Параметры командной строки nginx
nginx поддерживает следующие параметры:


 * -c <файл> — указывает использовать конфигурационный файл <файл> вместо файла по умолчанию.
 * -t — тестировать конфигурацию. nginx проверяет синтаксическую правильность конфигурации, а затем пытается открыть файлы, описанные в конфигурации.

Управление nginx
Управлять nginx можно с помощью сигналов. Номер главного процесса по умолчанию записывается в файл /usr/local/nginx/logs/nginx.pid. Изменить имя этого файла можно при конфигурации сборки или же в nginx.conf директивой pid. Главный процесс поддерживает следующие сигналы:
 * TERM, INT быстрое завершение
 * QUIT плавное завершение
 * HUP изменение конфигурации, запуск новых рабочих процессов с новой конфигурацией, плавное завершение старых рабочих процессов
 * USR1 переоткрытие лог-файлов
 * USR2 обновление исполняемого файла
 * WINCH плавное завершение рабочих процессов

Управлять рабочими процессами по отдельности не нужно. Тем не менее, они тоже поддерживают некоторые сигналы:
 * TERM, INT быстрое завершение
 * QUIT плавное завершение
 * USR1 переоткрытие лог-файлов

Изменение конфигурации

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

Предположим, на FreeBSD 4.x команда
 * ps ax -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'

показывает примерно такую картину:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sb
 * 33127 33126 nobody  0.0  1380 kqread nginx: worker process (nginx)
 * 33128 33126 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 33129 33126 nobody  0.0  1364 kqread nginx: worker process (nginx)

Если послать сигнал HUP главному процессу, то картина может быть такой:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sb
 * 33129 33126 nobody  0.0  1380 kqread nginx: worker process is shutting down (n
 * 33134 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 33135 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 33136 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)

Один старый рабочий процесс 33129 всё ещё продолжает работать. По истечении некоторого времени он завершается:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sb
 * 33134 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 33135 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 33136 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)

Ротация лог-файлов

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

Обновление сервера на лету

Для обновления сервера нужно записать на место старого исполняемого файла новый. Затем нужно послать сигнал USR2 главному процессу — он переименует свой файл с номером процесса в файл с суффиксом .oldbin, например, /usr/local/nginx/logs/nginx.pid.oldbin, после чего запустит новый исполняемый файл, а тот в свою очередь — свои рабочие процессы:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sb
 * 33134 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 33135 33126 nobody  0.0  1380 kqread nginx: worker process (nginx)
 * 33136 33126 nobody  0.0  1368 kqread nginx: worker process (nginx)
 * 36264 33126 root    0.0  1148 pause  nginx: master process /usr/local/nginx/sb
 * 36265 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36266 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36267 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)

Теперь все рабочие процессы наравне принимают запросы. Если послать сигнал WINCH первому главному процессу, то он пошлёт своим рабочим процессам сообщение о плавном выходе, и они будут постепенно выходить:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sb
 * 33135 33126 nobody  0.0  1380 kqread nginx: worker process is shutting down (n
 * 36264 33126 root    0.0  1148 pause  nginx: master process /usr/local/nginx/sb
 * 36265 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36266 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36267 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)

При использовании метода rtsig новые процессы могут не принимать соединения даже после того, как старому главному процессу послан сигнал WINCH. В этом случае новому главному процессу нужно посылать сигнал USR1 до тех пор, пока новые процессы не начнут принимать соединения.

По истечении времени запросы будут обрабатывать только новые рабочие процессы:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 33126    1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sb
 * 36264 33126 root    0.0  1148 pause  nginx: master process /usr/local/nginx/sb
 * 36265 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36266 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36267 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)

Нужно заметить, что старый процесс не закрывает свои listen сокеты и при необходимости ему можно сказать, чтобы он снова запустил свои рабочие процессы. Если работа нового исполняемого файла по каким-то причинам не устраивает, то можно сделать следующее:


 * Послать старому главному процессу сигнал HUP. Старый процесс, не перечитывая конфигурации, запустит новые рабочие процессы. После этого можно плавно завершить новые процессы, послав их главному процессу QUIT.
 * Послать новому главному процессу сигнал TERM, он пошлёт сообщение о немедленном выходе рабочим процессам и все они практически сразу же завершатся. По выходу нового главного процесса старый запустит новые рабочие процессы.
 * Если же новые процессы не завершаются, то нужно послать им сигнал KILL. По выходу нового главного процесса старый запустит свои рабочие процессы.
 * Если новый главный процесс выходит, то старый процесс убирает суффикс .oldbin из имени файла с номером процесса.
 * Если же обновление прошло удачно, то старому процессу нужно послать сигнал QUIT, и у нас остаются только новые процессы:
 * PID PPID USER    %CPU   VSZ WCHAN  COMMAND
 * 36264    1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sb
 * 36265 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36266 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36267 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)
 * 36267 36264 nobody  0.0  1364 kqread nginx: worker process (nginx)