У меня проблема с развертыванием приложения Django с помощью Gunicorn и Supervisor. Хотя я могу заставить Gunicorn обслуживать мое приложение (установив правильный PYTHONPATH и выполнив соответствующую команду, ту из конфигурации супервизора), я не могу заставить супервизора запускать его. Он просто не увидит мое приложение. Я не знаю, как убедиться, что файл конфигурации в порядке.
Вот что говорит 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). Любое решение для этого?
Правильный ответ - руководитель требует перечитать и обновить при размещении нового файла конфигурации. Перезагрузка - это не выход, так как это повлияет на другие службы. Пытаться:
supervisorctl reread
supervisorctl update
У меня была такая же проблема,
sudo service supervisord reload
сделал свое дело, хотя я не знаю, является ли это ответом на ваш вопрос.
Убедитесь, что файлы конфигурации вашего супервизора заканчиваются на .conf
Мне потребовалось время, чтобы понять это. Надеюсь, это поможет следующему человеку.
Перезагрузка главного процесса супервизора может сработать, но будет иметь непредвиденные побочные эффекты, если супервизор отслеживает более одного процесса.
Правильный способ сделать это - выпустить supervisorctl reread что заставляет его сканировать файлы конфигурации на предмет любых изменений:
root@debian:~# supervisorctl reread
gunicorn: changed
Затем просто перезагрузите это приложение:
root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started
У меня была похожая проблема ( 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 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 как пример того, как должна выглядеть минимальная конфигурация.
Я нашел это решение наиболее удобным:
РЕДАКТИРОВАТЬ: перед этим проверьте свой путь 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 () точно так же, как reloadConfig (функция do_reread) supervisorctl.
Поэтому я думаю, что повторное чтение не требуется, если вы вызываете обновление после него.
Судя по выходным данным git blame, так было по крайней мере с июля 2009 года.
Вот контрольный список:
Новый файл конфигурации должен быть назван в соответствии с шаблоном включения, настроенным в /etc/supervisord.conf:
[include]
files=supervisord.d/*.ini
Как мы видим в моем случае, spam.ini будет включен, а spam.conf - нет.
Если вы создали новый файл путем копирования старого, убедитесь, что действительно изменили [program:] линия. Потому что, если вы настолько глупы, что имеете два файла для одной программы, supervisorctl reread оставит вас с этим безнадежным сообщением об ошибке в качестве наказания:
No config updates to processes
Если ваш файл обнаружен, supervisorctl reread должен сказать что-то вроде:
spam: available
Затем, supervisorctl update spam должен как запустить его, так и отобразить в supervisorctl status.
Я обнаружил, что скрипты init.d ненадежны в различных версиях Ubuntu / Debian. Способ сделать это так:
sudo supervisorctl reload
Я установил supervisrod с yum install, который установил супервизор версии v2. *. Supervisor поддерживает внешние включения только начиная с версии 3. Вместо этого пришлось использовать easy_install, чтобы установить supervisor v3.
Будьте осторожны с символическими ссылками и включаемыми файлами в Supervisor.
Это позволит любому человеку с привилегией w на /home/myapp/live/deploy/supervisord_live.ini изменить ini файл и запустить любой вредоносный код.
это ini Файл должен находиться в каталоге conf вашего руководителя или в любом его подкаталоге.