Супервизор всегда выходит из процесса со статусом выхода 0; неожиданно'

13

В настоящее время я перестраиваю свой VPS, и я хотел бы использовать супервизор для управления процессами gunicorn / wsgi django. Дело в том, что супервизор продолжает выходить из процессов:

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 явно в конфигурацию, но это, похоже, тоже ничего не меняет. Похоже, что процесс создан правильно, но руководитель считает, что это не так.

У кого-нибудь есть подсказка, как это решить?

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

Bjorn
источник

Ответы:

12

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

Смотрите руководящие документы .

Дрю Блохл
источник
gunicorn не деамонизирует себя по умолчанию, но я установил его в своем конфигурационном файле. Я удалил его, спасибо за указание на это.
Бьорн
4

Хорошо, после некоторого недоумения я понял, что это как-то связано с пользователями. Я пытался запустить свои дочерние процессы как определенный пользователь. После удаления строки (см. Мой конфиг ниже) все работает нормально.

Конфиг Gunicorn:

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
Bjorn
источник
1
Просто быстрое замечание, что если вы хотите конкретизировать это, подсказка myuser и запуск gunicorn. Обычно подозреваемыми являются файлы журнала и pid, недоступные для записи. В качестве альтернативы вашему приложению также могут потребоваться разрешения на доступ к файлам. И просто быстрое замечание, что для лучшей поддержки супервизора вы должны обновить его до 0.10, поскольку мы исправили проблему с перезапуском gunicorn через supervisord (или runit в этом отношении).
Пол Дж. Дэвис
0

Я получил аналогичную ошибку при попытке запустить демон http под супервизором.

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

duckhunt
источник