Supervisor не загружает новые файлы конфигурации

У меня проблема с развертыванием приложения Django с использованием Gunicorn и Supervisor. Хотя я могу сделать так, чтобы Gunicorn обслуживал мое приложение (установив правильный PYTHONPATH и выполнив соответствующую команду, например, из конфигурации supervisord), я не могу заставить supervisor запускать его. Он просто не увидит мое приложение. Я не знаю, как убедиться, что файл конфигурации в порядке.

Вот что говорит supervisorctl:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

Я запускаю его на Ubuntu 10.04 со следующим конфигом:

Файл /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

В /etc/supervisor/supervisord.conf в конце файла находится:

[include]
files = /etc/supervisor/conf.d/*.conf

и вот символическая ссылка на мой конфигурационный файл:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

все выглядит хорошо для меня, но supervisorctl просто продолжаю говорить myapp_live: ERROR (no such process). Любое решение для этого?

У меня была такая же проблема,

sudo service supervisord reload

сделал свое дело, хотя я не знаю, если это ответ на ваш вопрос.

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

supervisorctl reread
supervisorctl update

Убедитесь, что ваши файлы conf supervisor заканчиваются на .conf

Мне понадобилось время, чтобы понять это. Надеюсь, это поможет следующему человеку.

Перезагрузка главного процесса супервизора может сработать, но у него будут непредвиденные побочные эффекты, если супервизор контролирует более одного процесса.

Правильный способ сделать это - выполнить команду, supervisorctl rereadкоторая заставляет его сканировать файлы конфигурации на наличие изменений:

root@debian:~# supervisorctl reread
gunicorn: changed

Затем просто перезагрузите это приложение:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

Я столкнулся с этой проблемой, используя пакет supervisor, версия 3.0a8-1.1 из Ubuntu Server 12.10. Я решил проблему, прочитав встроенную справку:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

В частности, вы хотите использовать синтаксис:

sudo supervisorctl restart myapp_live:*

Как указано в документации по адресу: http://supervisord.org/configuration.html#programx-section - «Раздел [program: x] фактически представляет« однородную группу процессов »для супервизора (начиная с версии 3.0)». Так что, возможно, проблема впервые появилась в версии 3.0.

PS: я новичок в супервизоре; Я использую https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor в качестве примера того, как должна выглядеть минимальная конфигурация.

У меня была похожая проблема ( myapp_live: ERROR (no such process)), и это потому, что мое определение процесса было

[program: myapp_live]

когда это должно было быть

[program:myapp_live]

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

Я нашел это решение наиболее удобным:

РЕДАКТИРОВАТЬ: перед этим проверьте ваш путь supervisorctl с помощью, which supervisorctlчтобы убедиться, что вы добавляете правильный путь к sudoers.

Добавьте эту строку в файл sudoers, используя visudo(где: myappuser- пользователь, которому нужно перезапустить ваше приложение, myapp- имя приложения):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

А потом просто:

sudo supervisorctl restart myapp

Вы не привязаны к сценариям запуска дистрибутива и даете пользователю довольно узкие права на перезапуск вашего приложения gunicorn. Кроме того, вам не нужно заботиться о pid. Команда не запрашивает пароль, поэтому она подходит для сценариев bash / fabric с автоматическим развертыванием. С другой стороны - вы должны знать, что если supervisorctl уязвим к некоторой ошибке, вызывающей выполнение кода, злоумышленник может использовать эту привилегию sudo для запуска кода от имени пользователя root (но, насколько я знаю, такой ошибки не было обнаружено для supervisord и найти такую ​​уязвимость очень важно).

Читая код supervisorctl.py здесь: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Вы можете видеть, что обновление supervisorctl (функция do_update) вызывает reloadConfig () точно так же, как и повторное чтение supervisorctl (функция do_reread).

Поэтому я думаю, что повторное чтение вызова не нужно, если вы вызываете обновление после него.

По результатам мерзавца, это было так, по крайней мере, с июля 2009 года.

Вот контрольный список:

1. Новый файл конфигурации должен быть назван в соответствии с шаблоном включения, настроенным в /etc/supervisord.conf:

   [include]
   files=supervisord.d/*.ini
   

   Как мы видим в моем случае, spam.ini будет включен, а spam.conf - нет.

2. Если вы создали новый файл, скопировав старый, обязательно измените [program:]строку. Потому что, если вы настолько глупы, как наличие двух файлов для одной и той же программы, supervisorctl rereadвы получите это безнадежное сообщение об ошибке в качестве наказания:

   No config updates to processes
   

3. Если ваш файл обнаружен, supervisorctl rereadследует сказать что-то вроде:

   spam: available
   

4. Затем supervisorctl update spamследует запустить его и сделать так, чтобы он появился в supervisorctl status.

Я обнаружил, что сценарии init.d ненадежны в различных версиях Ubuntu / Debian. Способ сделать это так:

sudo supervisorctl reload

Будьте осторожны с символическими ссылками и включайте файлы в Supervisor. Это позволило бы любому человеку с привилегией w на /home/myapp/live/deploy/supervisord_live.ini изменить INI-файл и запустить любой вредоносный код. Эти INI-файлы должны находиться в каталоге conf вашего супервизора или в любом его подкаталоге.

Я установил supervisrod с помощью yum install, который установил супервизор версии v2. *. Supervisor поддерживает внешние включения только из версии 3. Пришлось использовать easy_install вместо этого, чтобы установить supervisor v3.