Sellerie: WorkerLostError: Arbeiter verlassen vorzeitig: Signal 9 (SIGKILL)

Question

Ich benutze Sellerie mit RabbitMQ in meiner Django app (auf Elastic Beanstalk) Hintergrundaufgaben zu verwalten und ich daemonisierte es mit Supervisor. Das Problem ist jetzt, ist, dass eine der Periode Aufgabe, die ich definiert versagt (nach einer Woche, in der es richtig gearbeitet hat), die Fehler, die ich habe ist:

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

alle Supervisor verwalteten Prozesse und läuft richtig (supervisorctl status sagt RUNNING).

habe ich versucht, mehrere Protokolle auf meiner EC2-Instanz zu lesen, aber niemand scheint mir bei der Suche zu helfen, was die Ursache für die SIGKILL ist. Was soll ich machen? Wie kann ich untersuchen?

Das sind meine Sellerie Einstellungen:

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 

Jahr Dies ist mein 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: nach dem Neustart Sellerie schlagen das Problem bleibt :(

edit 2: geändert killasgroup = true zu killasgroup = false und das Problem bleibt

Answer 1

Die SIGKILL, die Ihr Arbeiter erhalten hat, wurde von einem anderen Prozess initiiert. Ihre Supervisord-Konfiguration sieht gut aus und die Killas-Gruppe würde nur einen vom Supervisor initiierten Kill betreffen (z. B. das CTL oder ein Plugin) - ohne diese Einstellung hätte sie das Signal ohnehin an den Dispatcher gesendet, nicht an das Kind.

Wahrscheinlich haben Sie einen Speicherverlust und die oomkiller OS ist Ermorden Ihren Prozess für schlechtes Verhalten.

grep oom /var/log/messages. Wenn Sie Nachrichten sehen, ist das Ihr Problem.

Wenn Sie nichts finden, versuchen Sie den periodischen Prozess manuell in einer Shell ausgeführt wird:

MyPeriodicTask().run()

Und sehen, was passiert. Ich würde System- und Prozessmetriken von oben in einem anderen Terminal überwachen, wenn Sie keine gute Instrumentierung wie Kaktus, Ganglien usw. für diesen Host haben.