Seler: WorkerLostError: Pracownik zakończył pracę przedwcześnie: sygnał 9 (SIGKILL)

Question

Używam Selera z RabbitMQ w mojej aplikacji Django (na Elastic Beanstalk) do zarządzania zadaniami tła i dememinizowałem je za pomocą Inspektora. Problem teraz jest to, że jednym z zadań, że okres zdefiniowany zawodzi (po tygodniu, w którym działał poprawnie), błąd Mam to:

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

wszystkie procesy są zarządzane przez przełożonego działa poprawnie (supervisorctl status mówi RUNNNING).

Próbowałem przeczytać kilka dzienników na mojej instancji EC2, ale nikt nie wydaje mi się pomóc w ustaleniu, co jest przyczyną SIGKILL. Co powinienem zrobić? Jak mogę zbadać?

Są to moje ustawienia seler:

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 

to moja 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: po ponownym uruchomieniu seler pokonać problem pozostaje :(

edit 2: changed killasgroup = true na killasgroup = false i problem pozostaje

Answer 1

SIGKILL pracownik otrzymany został zainicjowany przez inny proces. Twoja konfiguracja supervisord wygląda dobrze, a grupa killasgroup wpłynie tylko na zabójstwo zainicjowane przez nadzorcę (np. Ctl lub wtyczkę) - i bez tego ustawienia wysłałoby sygnał do dyspozytora, a nie dziecko.

Najprawdopodobniej masz wyciek pamięci, a oomkiller systemu operacyjnego zabija proces w poszukiwaniu złego zachowania.

grep oom /var/log/messages. Jeśli widzisz wiadomości, to twój problem.

Jeśli nie znajdziesz nic, spróbuj uruchomić proces okresowej ręcznie w powłoce:

MyPeriodicTask().run()

i zobaczyć, co się dzieje. Monitorowałbym system i dane procesowe od góry w innym terminalu, jeśli nie masz dobrego oprzyrządowania, takiego jak kaktus, zwoje itd. Dla tego hosta.