Как устранить тайм-аут выхода из celeryd при работе на Heroku (ошибка R12)?

Я использую celeryd на динамометрическом стенде Heroku. Когда я закрываю его, и он ранее обработал (даже завершил) по крайней мере одну задачу, он не закрывается должным образом, и я получаю сообщение об ошибке R12 (время ожидания выхода) от Heroku.

Вот как я запускаю celeryd из своего Procfile (через Django и django-celery):

celeryd: python manage.py celeryd -E --loglevel=INFO

Вот что я делаю, чтобы вызвать его:

> heroku ps:scale web=0 celeryd=0 --app myapp

И вот вывод журнала, который я получаю:

2012-09-07T12:56:31+00:00 heroku[celeryd.1]: State changed from up to down
2012-09-07T12:56:31+00:00 heroku[api]: Scale to celeryd=0, web=1 by [email protected]
2012-09-07T12:56:32+00:00 heroku[web.1]: State changed from up to down
2012-09-07T12:56:32+00:00 heroku[api]: Scale to web=0 by [email protected]
2012-09-07T12:56:34+00:00 heroku[celeryd.1]: Stopping all processes with SIGTERM
2012-09-07T12:56:35+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2012-09-07T12:56:37+00:00 heroku[web.1]: Process exited with status 143
2012-09-07T12:56:43+00:00 heroku[celeryd.1]: Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of SIGTERM
2012-09-07T12:56:43+00:00 heroku[celeryd.1]: Stopping remaining processes with SIGKILL
2012-09-07T12:56:45+00:00 heroku[celeryd.1]: Process exited with status 137

Первоначально я испытал это на сельдерее 2.5.5. Теперь я обновился до 3.0.9, и у меня все еще та же проблема.

Насколько я могу судить, все мои задачи выполнены. Эту ошибку надежно воспроизвести, запустив одну задачу на динамометрическом стенде с сельдереем, дав ей достаточно времени для завершения, а затем выключив динамометрический стенд.

Я не знаю, что еще проверить. Любая идея, как я могу устранить эту проблему? Что может помешать celeryd ответить на SIGTERM Heroku, когда задача уже выполнена?


person Henrik Heimbuerger    schedule 07.09.2012    source источник
comment
В конце концов разобрались с этим? Я столкнулся с той же проблемой.   -  person Murph    schedule 01.05.2013
comment
@Murph Я так и не понял, но я больше не могу это воспроизвести. Однако сейчас я использую совершенно другую конфигурацию, с последними версиями celery и django-celery и гораздо более сложным Procfile, с отдельными процессами для нескольких рабочих, cam и beat на одном и том же динамометрическом стенде.   -  person Henrik Heimbuerger    schedule 02.05.2013
comment
Я тоже застрял в этой проблеме, см. github.com/yuvadm/heroku-periodical /проблемы/1   -  person Yuval Adam    schedule 24.06.2013
comment
У меня все еще/снова возникает эта проблема на celery 3.1.11. Не решен к сожалению. :(   -  person Henrik Heimbuerger    schedule 30.07.2014


Ответы (2)


Я сталкиваюсь с той же проблемой. Я не уверен, но может быть исправлено:

Рабочий процесс с аргументом -B не завершил должным образом битовый экземпляр.

Поэтому, если вы используете celery beat внутри рабочего экземпляра, вам может потребоваться обновление.

person Scott Coates    schedule 07.01.2014
comment
Действительно, звучит неплохо, спасибо за подсказку! Жаль, что они не отметили соответствующий тикет в своем журнале изменений. - person Henrik Heimbuerger; 07.01.2014
comment
Просто остановил и перезапустил своих рабочих и все еще получаю ту же проблему. Однако, похоже, это проблема с Celerybeat. В журналах я вижу, что все рабочие процессы успешно закрываются, но затем INFO/MainProcess beat: Shutting down... и вскоре после этого heroku[worker.1]: Error R12 (Exit timeout) -> At least one process failed to exit within 10 seconds of SIGTERM - person johnboiles; 20.02.2014
comment
К вашему сведению, у меня была такая же проблема при запуске Celerybeat на отдельном динамометрическом стенде и при запуске его на том же, что и рабочие. - person johnboiles; 20.02.2014

Мне кажется, что сельдерей не улавливает сигнал SIGTERM и не реагирует на него, ожидая, пока не прибудет SIGKILL.

Этот запрос на вытягивание может вам помочь: https://github.com/cybertoast/celery/commit/e9a007b982b0f9268174ae94b351a9275eaef4a3

person Neil Middleton    schedule 26.06.2013
comment
Я не совсем понимаю, как это связано. Это похоже на скрипт init.d для CentOS, как это поможет мне на Heroku? Это также, кажется, просто пытается «убить сильнее». Heroku уже делает это для меня, вопрос в том, почему Celery не отвечает должным образом на SIGTERM в первую очередь. - person Henrik Heimbuerger; 01.09.2013