Celery: Reinicio de problemas de apio y mejor archivo de configuración supervisado

Los procesos generados al recibir la señal KILL son realmente extraños. No veo ese comportamiento cuando se usa fuera de supervisord , así que tal vez esto sea causado por eso.

Si instala el módulo setproctitle , el apio debería informar el tipo de proceso en los listados de ps , ¿podría hacer eso para investigar qué tipo de proceso se crea?

( easy_install setproctitle )

Establecer el tiempo de espera en 600 probablemente sea bueno. ¿Hay alguna configuración para el infinito (tal vez con una advertencia si tarda demasiado)? Cuando celeryd se elimina a través TERM (que es la señal de apagado preferida), deja de recibir mensajes y espera a que finalicen las tareas que se están ejecutando actualmente. Y supongo que para la mayoría de las aplicaciones, la terminación a mitad de la ejecución no es aceptable.

En cuanto a la generación de procesos: setproctitle y observar los identificadores de procesos fue útil. No es un proceso de desove. Los procesos de trabajo permanecen vivos cuando se elimina el proceso principal.
Esta es una simulación de reinicio supervisado con eliminación manual y tiempo de espera cero:

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6101 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6108 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 nadovmeste:~# kill 6101 & kill -9 6101 &

pd-afx:

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6867 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6875 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 6108 ?        S      0:00 [celeryd.PoolWorker-1]       

Pude reproducir esto solo con una carrera artificial entre kill y kill -9 . A veces, el trabajador es asesinado correctamente. El problema parece ser específico del supervisor porque cuando inicio celeryd desde la consola no tengo suerte al reproducirlo.

Pude reproducir esto con scripts iniciados en la consola después de varios intentos:

/home/nadovmeste/envs/nadovmeste/bin/python /home/nadovmeste/src/nadovmeste/manage.py celeryd -B --loglevel=INFO&

y luego en otra sesión de terminal:

nadovmeste:~# ps -afx

 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash
 9343 pts/2    Sl     0:00          \_ [celeryd.MainProcess] Running... (-B --loglevel=INFO)                                                           
 9350 pts/2    S      0:00              \_ [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00              \_ [celerybeat]     

nadovmeste:~# kill 9343 & kill -9 9343

nadovmeste:~# ps -afx

 4526 ?        Ss     0:00  \_ sshd: root@pts/1 
 4529 pts/1    Ss     0:00  |   \_ -bash
 9366 pts/1    R+     0:00  |       \_ ps -afx
 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash    
 ...
 9350 pts/2    S      0:00 [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00 [celerybeat]

No he encontrado ninguna opción especial para el tiempo de espera infinito con advertencia en los documentos supervisados. Probablemente un número muy grande será suficiente si es lo que queremos.

Tal vez sea algo relacionado con celerybeat porque pude reproducir el problema para celeryd iniciado en la consola solo después de usar la opción -B .

Si estoy probando algunas tareas de apio localmente y uso la opción -B, a veces el proceso no se cancela cuando uso ctrl-c.

No puedo reproducir esto localmente. Por cierto, ¿estás ejecutando la rama maestra? Acabo de arreglar un error que podría bloquear el apagado. Si pudieras probar con esto sería bueno.

Sí, estoy ejecutando la rama maestra más reciente. Vi su confirmación de corrección de errores y esperaba que ayudara, pero parece que no ayuda en mi caso: el último apio parece comportarse de la misma manera. Pero es posible que el problema inicial se resuelva; lo compruebo solo con una muerte inmediata. No puedo envolver mi mano alrededor de él ahora :) El problema de ctrl-c no es reproducible con mi configuración.

Entonces, el informe de error, simplificado: http://gist.github.com/401028 . Los resultados son siempre los mismos (no a veces). Tengo algunas tareas periódicas y otras no periódicas. Las tareas son simples y no toman mucho tiempo para terminar. ¿Es un error que los procesos secundarios permanezcan vivos después de eliminar el proceso principal? Si es así y no puede reproducirlo, intentaré proporcionar el proyecto mínimo.

El comportamiento de eliminación de celerybeat es interesante: cuando mato el proceso celerybeat colgante (?), el proceso de trabajo colgante (?) también se apaga.

@kmike Todavía no puedo reproducir con los comandos anteriores. ¿Tal vez porque estoy en OS X, o tal vez estás ejecutando Python 2.5? (Estoy ejecutando 2.6.1)

Podría ejecutarlo con --loglevel=DEBUG? Podría proporcionar información sobre dónde se detiene.

El proceso principal inicia el proceso de celerybeat, por lo que asumo que el proceso principal está esperando
para que celerybeat salga antes de que elimine los procesos restantes del grupo.

Pensé que el proceso principal se eliminó: no está visible en la lista de procesos. Sin embargo, no tengo mucha experiencia con la gestión de procesos.

Mi configuración fue Debian Lenny + python 2.5.

Intentaré ejecutar celeryd con --loglevel=DEBUG y reproducirlo en mi macbook.

hmm, tienes razón por supuesto. Es casi como si el proceso de ritmo tomara posesión de los procesos del grupo.

Acabo de intentar reproducir en Debian Lenny con python 2.5, y funciona justo ahí.
Intenté matar con TERM e INT.

Preguntar, gracias por la ayuda.

Creo que el problema inicial se resolvió con un mayor tiempo de espera de supervisión y su compromiso de corrección de errores. La simulación fue incorrecta porque uso los comandos kill -9 y envían la señal KILL en lugar de TERM. Con la señal TERM, los procesos se eliminan correctamente.

El supervisor usa la señal TERM, por lo que todo debería estar bien.

Pero lo que me asusta un poco es que no se investigó el error inicial. Intentaré reproducirlo y te cuento.

¡Ay! Lo siento mucho. No leí el tema con suficiente atención. ¡Sí! Eso es exactamente lo que sucede cuando lo matas con SIGKILL. La señal 9 no se puede captar, así que no hay nada que podamos hacer al respecto.

En caso de que todavía tenga problemas para despedir a sus trabajadores de Celery, puede intentar configurar stopasgroup=true antes de aumentar su stopwaitsecs .