django - Apio: WorkerLostError: Worker exit prematurely: signal 9(SIGKILL)

amazon-ec2 celery

Question

Uso Apile con RabbitMQ en mi aplicación Django (en Elastic Beanstalk) para administrar las tareas en segundo plano y lo demonicé con Supervisor. El problema ahora es que una de las tareas de período que definí está fallando (después de una semana en la que funcionó correctamente), el error que obtuve es:

[01/Apr/2014 23:04:03] [ERROR] [celery.worker.job:272] Task clean-dead-sessions[1bfb5a0a-7914-4623-8b5b-35fc68443d2e] raised unexpected: WorkerLostError(''Worker exited prematurely: signal 9 (SIGKILL).'',)
Traceback (most recent call last):
File "/opt/python/run/venv/lib/python2.7/site-packages/billiard/pool.py", line 1168, in mark_as_worker_lost
human_status(exitcode)),
WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL).

todos los procesos administrados por el supervisor están funcionando correctamente (el supervisorctl status dice RUNNNING).

Traté de leer varios registros en mi instancia de ec2, pero nadie parece ayudarme a descubrir cuál es la causa del SIGKILL. ¿Que debería hacer? ¿Cómo puedo investigar?

Estas son mis configuraciones de apio:

CELERY_TIMEZONE = ''UTC''
CELERY_TASK_SERIALIZER = ''json''
CELERY_ACCEPT_CONTENT = [''json'']
BROKER_URL = os.environ[''RABBITMQ_URL'']
CELERY_IGNORE_RESULT = True
CELERY_DISABLE_RATE_LIMITS = False
CELERYD_HIJACK_ROOT_LOGGER = False

Y este es mi supervisor .conf:

[program:celery_worker]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery worker -A com.cygora -l info --pidfile=/opt/python/run/celery_worker.pid
startsecs=10
stopwaitsecs=60
stopasgroup=true
killasgroup=true
autostart=true
autorestart=true
stdout_logfile=/opt/python/log/celery_worker.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_worker.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1
[program:celery_beat]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery beat -A com.cygora -l info --pidfile=/opt/python/run/celery_beat.pid --schedule=/opt/python/run/celery_beat_schedule
startsecs=10
stopwaitsecs=300
stopasgroup=true
killasgroup=true
autostart=false
autorestart=true
stdout_logfile=/opt/python/log/celery_beat.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_beat.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1

editar: después de reiniciar el compás de apio, el problema persiste :(

edición 2: killasgroup cambiado = verdadero a killasgroup = falso y el problema permanece

Answer 1

El SIGKILL que recibió su trabajador fue iniciado por otro proceso. Su configuración de supervisión se ve bien, y el killasgroup solo afectaría a un kill iniciado por un supervisor (por ejemplo, el ctl o un plugin), y sin esa configuración habría enviado la señal al despachador de todos modos, no al niño.

Lo más probable es que tengas una pérdida de memoria y el oomkiller del sistema operativo está asesinando a tu proceso por un mal comportamiento.

grep oom /var/log/messages . Si ves mensajes, ese es tu problema.

Si no encuentra nada, intente ejecutar el proceso periódico manualmente en un shell:

MyPeriodicTask().run()

Y mira lo que pasa. Controlaría las métricas del sistema y del proceso desde la parte superior en otra terminal, si no tienes una buena instrumentación como cactus, ganglios, etc. para este host.