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

У мене проблема з розгортанням програми 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). Будь-яке рішення для цього?

У мене був той самий випуск, a

sudo service supervisord reload

зробив трюк, хоча я не знаю, чи це відповідь на ваше запитання.

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

supervisorctl reread
supervisorctl update

Переконайтеся, що конфігураційні файли вашого керівника закінчуються в .conf

Зайняв мене час, щоб зрозуміти це. Сподіваємось, це допомагає наступній людині.

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

Правильний спосіб зробити це - видавати, supervisorctl rereadщо змушує його сканувати конфігураційні файли на предмет будь-яких змін:

root@debian:~# supervisorctl reread
gunicorn: changed

Потім просто перезавантажте цю програму:

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

Я зіткнувся з цією проблемою, використовуючи пакет супервізора, версія 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 - "Розділ [програма: 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]

Хоча це не стосується поставленого питання, мене тут привів пошук, який шукає рішення моєї проблеми, тому, сподіваємось, і інші люди знайдуть його тут.

Я вважаю це рішення найбільш зручним:

EDIT: перед цим перевірте шлях свого supervisorctl, використовуючи, which supervisorctlщоб переконатися, що ви додаєте правильний шлях до sudoers.

Додайте цей рядок до файлу sudoers, використовуючи visudo(де: myappuser- користувач, якому потрібно перезапустити додаток, myapp- ім’я програми):

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

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

sudo supervisorctl restart myapp

Ви не прив'язані до сценаріїв запуску дистрибутива, і ви надаєте досить вузькі привілеї користувачеві перезапустити додаток. Крім того, вам не потрібно піклуватися про pid. Команда не буде запитувати пароль, тому вона підходить для автоматичного розгортання bash / fabric скриптів. З іншого боку - ви повинні знати, що якщо supervisorctl вразливий до якоїсь помилки, що спричиняє виконання коду, зловмисний користувач може використовувати цю привілей sudo для запуску коду як root (але, наскільки я знаю, такої помилки не було виявлено для нагляду та важливо знайти таку вразливість).

Прочитавши код supervisorctl.py тут: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

Ви можете бачити, що оновлення supervisorctl (функція do_update) викликає reloadConfig () саме так, як це переглядає supervisorctl (функція do_reread).

Тому я думаю, що перепрочитати дзвінки не потрібно, якщо ви викликаєте оновлення після нього.

З вини git вини це було, як мінімум, з липня 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. Це дозволить будь-якій особі, яка має привілей на /home/myapp/live/deploy/supervisord_live.ini, змінити файл ini та запустити будь-який шкідливий код. Ці ini-файли повинні знаходитись у конф-каталозі вашого керівника або в будь-якому підрозділі під ним.

Я встановив supervisrod з yum install, який встановив супервізор версії v2. *. Супервізор підтримує зовнішнє, включає лише версію 3. Для встановлення Supervisor v3 довелося скористатися easy_install.