Я пытаюсь получить рабочую настройку supervisor / gunicorn / django на vagrant. Я использую python-watchdog, чтобы попытаться перезапустить Gunicorn при изменении кода.
Я использую следующую конфигурацию супервизора для Gunicorn:
[program:someapp]
environment=PYTHONPATH='/vagrant/libs/unmodified/django-error-capture-middleware/src:/vagrant:/home/vagrant/.virtualenvs/someapp/lib/python2.7/site-packages:/vagrant/wsgi',DJANGO_SETTINGS_MODULE=someapp.settings.vagrant
command=/home/vagrant/.virtualenvs/someapp/bin/gunicorn --bind 0.0.0.0:80 --pid=/home/vagrant/.gunicorn.pid --preload --workers=1 --debug --log-level debug --error-logfile - --access-logfile - vagrant_wsgi:application
user=root
group=root
redirect_stderr=true
stdout_logfile = /vagrant/logs/gunicorn.log
stderr_logfile = /vagrant/logs/gunicorn.log
stdout_logfile_maxbytes=0
autostart=true
autorestart=true
stdout_events_enabled=true
loglevel=debug
Все это прекрасно работает. Сторожевой таймер тоже работает нормально. Однако, когда я использую сторожевой таймер для запуска kill -HUP [pidofgunicorn], иногда он не перезагружается полностью. Иногда django даже сообщает об отсутствии модулей, когда они были раньше (я вообще не модифицировал sys.path).
Если я использую сторожевой таймер для запуска supervisorctl restart someapp, работает нормально. Однако это занимает намного больше времени, особенно на экземпляре виртуального бокса.
Могу ли я что-то сделать, чтобы заставить Gunicorn изящно перезаряжаться и действительно видеть внесенные изменения?
Проблема в параметре --preload.
В первый решение - не использовать --preload.
В второй решение заключается в следующем:
# Reload a new master with new workers
kill -s USR2 $PID
# Graceful stop old workers
kill -s WINCH $OLDPID
# Graceful stop old master
kill -s QUIT $OLDPID
В третий решение - использовать пакет https://github.com/flupke/rainbow-saddle это хорошо работает с супервизором.