Nginx и Runit .... что такое лучшая практика - PullRequest
Новая
       22

Nginx и Runit .... что такое лучшая практика

3 голосов
/ 02 марта 2012

Я не совсем уверен, что nginx всегда работает.Мое понимание сценария init.d оправдывает запуск и остановку nginx.Это правильно?Затем в документации говорится, что daemon = off;

Теперь я хотел бы использовать runit, и ниже приведен мой скрипт запуска runit: 

#!/bin/sh
exec /etc/init.d/nginx start

Я заметил, что новый PIDвсегда создается.

Итак, в итоге: 1) У меня нет этого утверждения в файле nginx: 

daemon = off;

2) Я использую приведенный выше скрипт runit, но он всегда создаетновый PID.

Итак ... что является лучшей практикой для обеспечения того, чтобы nginx всегда работал.

Я, кстати, использую monit, но запускаю его для создания демона hte.

В качестве теста я убил nginx с помощью killall -9 nginx, и я сделал ps aux |grep nginx и заметил, что я получил новый pid.Итак ... мне все еще нужен рунит?

Ответы [ 2 ]

2 голосов
/ 24 октября 2016

Сценарии под /etc/init.d связаны с sysvinit, почтенным и, к сожалению, довольно нарушенным подходом к управлению сервисами UNIX. Видите, процессы в UNIX образуют дерево: у каждого процесса есть родитель, процесс, который его запустил. Родитель имеет большой контроль над своими потомками и, что важно, уведомляется, когда умирает дочерний процесс. Практически тривиально поддерживать процесс в рабочем состоянии или выключать его, если вы его родитель.

И есть проблема: сценарий службы sysvinit запускает службу, а затем завершает работу, оставляя службу запущенной. Родительский процесс службы пропал, что затрудняет поиск и отслеживание службы. Когда сценарию sysvinit предлагается остановить службу, ему необходимо определить, какой процесс следует остановить, используя ненадежную информацию.

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

Таким образом, в скрипте runit правильное выполнение - запуск самого nginx, а не сценария init.d. Это достаточно легко сделать. Однако по умолчанию nginx демонизирует себя, что означает, что он намеренно «убегает» от своего родительского процесса и становится очень трудно отследить. К счастью, такое поведение можно отключить, что является целью опции конфигурации daemon off;. Действительный скрипт runit для nginx выглядит следующим образом: 

#!/bin/sh
exec /usr/sbin/nginx -g "daemon off;"

Коротко и сладко. runit может очень хорошо управлять этим механизмом - он будет поддерживать работу nginx, и вы можете управлять им с помощью sv. Например, sv hup nginx говорит nginx перезагрузить свою конфигурацию. Конечно, PID изменится, если nginx аварийно завершит работу и будет перезапущен, или если вы намеренно попросите его перезапустить с помощью sv restart nginx, но runit с этим справится.

(Между прочим, никогда никогда когда-либо используйте kill -9, когда-либо. )

0 голосов
/ 06 марта 2012

Nginx имеет главный процесс, который управляет рабочими процессами.Он продолжает работать.Запустив nginx на переднем плане и позволяя управлять другим приложением, вы плохо изобретаете колесо.

...