2012-04-02 7 views
11

Dopo aver emesso il segnale TERM all'operatore Celery due volte (spegnimento a caldo e spegnimento a freddo) utilizzando l'interrupt di tastiera Ctlr-C, l'operatore di Celery viene semplicemente riagganciato. Non consuma messaggi o esegue attività (come previsto), ma non si arresta neanche.Perché il sedano non si spegne in modo pulito?

Ho eseguito strace sui processi di Celery per vedere cosa succede dietro la scena. Ecco il strace uscita sul PID del processo principale Sedano

strace -p 27867 
Process 27867 attached - interrupt to quit 
futex(0xb966a78, FUTEX_WAIT, 0, NULL 

Ed ecco cosa ho trovato facendo strace sui processi figli:

strace -p 27874 
Process 27874 attached - interrupt to quit 
select(4, [3], NULL, NULL, {0, 562000}) = 0 (Timeout) 
futex(0x871a808, FUTEX_WAKE, 1)   = 0 
select(4, [3], NULL, NULL, {1, 0})  = 0 (Timeout) 
futex(0x871a808, FUTEX_WAKE, 1)   = 0 
...................................................... 

So che potrei emettere un segnale KILL ai processi di sbarazzati di loro. Ma sono curioso di sapere cosa sta effettivamente impedendo l'arresto di questi processi e se è possibile fare qualcosa al riguardo.

software stack: Python 2.6.2, 2.4.6 sedano, CentOS 5.0

UPDATE: L'utilizzo della CPU è fino a quasi 0%. Queste attività sono piuttosto impegnative per la CPU, quindi questo non conferma attività attualmente attive.

risposta

3

Dal docs:

Se il lavoratore non sarà arresto dopo il tempo premuroso, ad esempio a causa di compiti bloccato in un infinito loop, è possibile utilizzare il segnale KILL per forzare terminare il lavoratore , ma ricorda che attualmente le attività di esecuzione di andranno perse (a meno che le attività non abbiano l'opzione di opzione acks_late ).

Anche da google groups:

celeryd non si spegne fino a quando tutte le attività attive sono stati elaborati, dove attiva significa i compiti che sono stati avviati sulla (non tutti compiti riservati). I messaggi riservati verranno rilasciati e il numero riconsegnato una volta chiuso il canale di connessione. Questo succede dopo che le attività attive sono ritornate. se non si dispone di un limite di tempo abilitato a , il celeryd non interromperà mai le attività all'arresto, anche se il completamento di DAYS.

+2

Non ci sono attività attive. Le attività che erano in esecuzione al momento dell'emissione del segnale di arresto erano finite. La lunghezza della coda rimane la stessa. Nulla viene inviato ai log. Ma i processi non stanno ancora terminando. Come ho detto, * posso * rilasciare un KILL e sbarazzarmi di loro. Ma questa non sarà una soluzione molto efficace. Per utilizzare in modo affidabile questo software, ho bisogno di essere in grado di fermarsi (e avviarlo) automaticamente con poco o nessun intervento manuale. – rubayeet

+1

Una buona soluzione per questo è demonizzare il sedano. Supervisord è un candidato eccellente. – hymloth

+1

Sto usando gli script di init generici per demonizzare i lavoratori: https://github.com/ask/celery/blob/master/contrib/generic-init.d/celeryd – rubayeet