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

У меня проблема с развертыванием приложения 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

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

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

supervisorctl reread
supervisorctl update

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

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

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

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

root@debian:~# supervisorctl reread
gunicorn: изменено

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

root@debian:~# supervisorctl restart gunicorn
gunicorn: остановлено
gunicorn: запущено

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

[program: myapp_live]

хотя оно должно быть

[program:myapp_live]

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

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

$ sudo supervisorctl help restart
restart <name>          Перезапустить процесс
restart <gname>:*       Перезапустить все процессы в группе
restart <name> <name>   Перезапустить несколько процессов или групп
restart all             Перезапустить все процессы

В частности, вам нужно использовать синтаксис:

sudo supervisorctl restart myapp_live:*

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

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

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

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

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

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

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

   Нет обновлений конфигурации для процессов
   

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

   spam: доступно
   

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

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

sudo supervisorctl reload

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

ИЗМЕНИТЬ: перед этим проверьте ваш путь 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 update (функция do_update) вызывает reloadConfig() точно так же, как supervisorctl reread (функция do_reread).

Так что я думаю, что вызов reread не обязателен, если вы вызываете update после него.

Согласно выводу git blame, это было так по крайней мере с июля 2009 года.

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

Будьте осторожны с символическими ссылками и включаемыми файлами в Supervisor.

Он позволит любому человеку с привилегиями записи на /home/myapp/live/deploy/supervisord_live.ini изменить файл ini и запустить любой вредоносный код.

Этот файл ini должен находиться внутри каталога конфигурации вашего supervisor или в любом подкаталоге под ним.

Еще одно, что мне пришлось сделать, это изменить права доступа к файлу скрипта, выполнив следующую команду:

chmod +x /etc/init.d/your_script

Этот учебник на Digital Ocean может быть очень полезным, чтобы помочь вам выяснить некоторые проблемы.

Это сработает:

sudo supervisorctl reread && sudo supervisorctl update && sudo supervisorctl restart all