Супервізор завжди виходить з процесу зі статусом "вихід 0"; не очікується '


13

Наразі я відновлюю свій vps, і я хотів би використовувати супервізор для управління процесами django guicorn / wsgi. Річ у тому, що супервізор продовжує виходити з процесів:

2010-07-23 14:54:40,575 INFO supervisord started with pid 31391
2010-07-23 14:54:41,582 INFO spawned: 'projectx' with pid 31395
2010-07-23 14:54:41,691 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:42,695 INFO spawned: 'projectx' with pid 31401
2010-07-23 14:54:42,801 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:44,806 INFO spawned: 'projectx' with pid 31404
2010-07-23 14:54:44,912 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:47,917 INFO spawned: 'projectx' with pid 31408
2010-07-23 14:54:48,022 INFO exited: projectx (exit status 0; not expected)
2010-07-23 14:54:49,023 INFO gave up: projectx entered FATAL state, too many start retries too quickly

Це конфігурація, яку я використовую:

[program:projectx]
command=/path/to/project/bin/gunicorn_django -c /path/to/project/project/gunicorn.conf.py /path/to/project/project/production.py
user=myuser
autostart=true
autorestart=true

Я вже двічі перевірив, і gunicorn_django робить статус повернення 0, коли він породжений правильно.

Я спробував явно додати конфігурацію exitcodes = 0,2, але, схоже, це теж не змінило. Схоже, процес породжений правильно, але керівник вважає, що цього не відбулося.

Хтось має підказку, як це вирішити?

Спасибі, Бьорн

Відповіді:


12

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

Див. Документи з нагляду .


gunicorn не деамонізує себе за замовчуванням, але я його встановив у своєму конфігураційному файлі. Я її зняв, дякую, що вказав на це.
Бьорн

4

Гаразд, після деяких спантеличених я зрозумів, що це має щось спільне з користувачами. Я намагався запускати мої дочірні процеси як певний користувач. Після видалення рядка (див. Мою конфігурацію нижче) все працює нормально.

Конфігурація гунікорна:

bind = "127.0.0.1:3305"
workers = 2

Конфігурація супервізора:

[program:projectx]
command=/path/to/project/bin/gunicorn_django -c /path/to/project/project/gunicorn.conf.py /path/to/project/project/production.py
; set the user here instead of in the gunicorn config.
user=user
autostart=true
autorestart=unexpected
stdout_logfile=/path/to/project/logs/project.log
redirect_stderr=true
exitcodes=1

1
Лише коротка зауваження, що якщо ви хочете втілити це, поскаржившись мійсеру та запустівши гарнітур, слід натякнути. Звичайними підозрюваними є файли журналу та pid, які не підлягають запису. Крім того, для вашої програми також можуть знадобитися файлові дозволи. І лише коротке зауваження, що для кращої підтримки супервізора вам слід оновити до 0,10, оскільки ми вирішили проблему з перезапуском зброї через supervisord (або runit для цього питання).
Пол Дж. Девіс

0

Я отримав подібну помилку при спробі виконання http-демона під наглядом.

Виправлено шляхом видалення старого файлу pid: httpd_pid

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.