On Tue, Sep 23, 2014 at 08:30:15AM +0200, Roberto De Ioris wrote: > > > Ciao a tutti, > > > > > > sto cercando la configrazione ottimale per fare partire celery con > > django in produzione. > > > > Uso nginx + uwsgi per l'applicazione principale e credevo leggendo [1] > > [2] che smart-attach-daemon avrebbe potuo risolvere il problema di > > garantirmi che un reload di uwsgi (uwsgi --reload) inviasse un segnale > > al processo di celery. > > > > Forse ho compreso male la documentazione che in effetti non dice > > esplicitamente cosa dovrebbe succedere ma solo :: > > > > > > Pidfile governed processes can survive death or reload of the master > > so long as their pidfiles are available and the pid contained > > therein matches a running pid. This is the best choice for processes > > requiring longer persistence, and for which a brutal kill could mean > > loss of data such as a database. > > > > smart-attach-daemon serve proprio ad evitare che un demone venga ucciso > durante un riavvio. Effettivamente celery (almeno nella mia mente) e' uno > di quei servizi che dovrebbe andare per fatti suoi, e quindi > smart-attach-daemon e' l'approggio giusto. > > Mi pare di capire pero' che tu invece vuoi che a ogni reload corrisponda > anche un restart di celery, in questo caso attach-daemon e' quello che ti > serve.
In effetti la vedo così. Se cambio la definizione dei task che invio, devo garantirmi che anche celery ne sia al corrente. Quindi con smart-attach-daemon l'unica cosa che fa è di avviare il servizio se non è avviato? > > Eventualmente con attach-daemon2 hai un controllo maggiore sul comportamento: > > https://github.com/unbit/uwsgi-docs/blob/master/AttachingDaemons.rst#--attach-daemon2 Ok, ora lo guardo, chiaramente avendo visto l'esempio proprio su celery mi ero fermato sandro *:-) _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python