Celery: WorkerLostError: Worker è uscito prematuramente: signal 9 (SIGKILL)

Question

Uso Celery con RabbitMQ nella mia app Django (su Elastic Beanstalk) per gestire le attività in background e l'ho demonizzato utilizzando Supervisor. Il problema ora, è che uno dei compiti periodo che ho definito sta fallendo (dopo una settimana in cui ha funzionato correttamente), l'errore che ho è:

[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). 

tutti i processi gestiti dal supervisore sono installato e funzionante correttamente (supervisorctl status dice RUNNING).

Ho provato a leggere diversi registri sulla mia istanza ec2 ma nessuno sembra aiutarmi a scoprire qual è la causa del SIGKILL. Cosa dovrei fare? Come posso indagare?

Queste sono le mie impostazioni di sedano:

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 

Un questo è il mio supervisord.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 

edit: dopo aver riavviato il sedano battere il problema rimane :(

modifica 2: cambiato killasgroup = true in killasgroup = false e il problema rimane

Answer 1

Il SIGKILL ricevuto dal lavoratore è stato avviato da un altro processo. La tua configurazione di supervisord ha un bell'aspetto e il killasgroup avrà effetto solo su un kill avviato dal supervisore (ad esempio il ctl o un plugin) - e senza quell'impostazione avrebbe comunque inviato il segnale al dispatcher, non al bambino.

Molto probabilmente si ha una perdita di memoria e l'oomkiller del sistema operativo sta assassinando il processo per un comportamento errato.

grep oom /var/log/messages. Se vedi i messaggi, questo è il tuo problema.

Se non trovate nulla, provare a eseguire manualmente il processo periodico in un guscio:

MyPeriodicTask().run()

e vedere cosa succede. Monitorerei il sistema e processerò le metriche dall'alto in un altro terminale, se non hai una buona strumentazione come cactus, gangli, ecc. Per questo host.