#celery

asksol: For now i will try to trigger an alert if a worker had a reserved job unattended for a period of time.

Hopefully will convince folks about an upgrade. Does upgrade has any feature which will prevent the issue.

several deadlocks were fixed

3.1 fixes some additional deadlocks that are impossible to fix in a bugfix release

e.g the worker may deadlock if a pool processes is killed while having acquired the posix semaphore

process-es

this is a rather rare event but is more likely to happen if revoke+terminate is used

asksol: Thanks a ton. I believe the rare event is rather the case. We do revoke+terminate like ladygaga hairdo. I will first try to remove terminate=true flag out. Eventually will do an upgrade to have all the goodies.

ah, latest 3.0.x mostly fixes TERM and other signals

cool.

3.1 fixes KILL as well

Ok. I am sending sigkill :(.

you're unlikely to be able to backport that fix to 3.0 as it involves rewriting everything ;)

so it no longer uses posix semaphores

you can try 3.1rc already, as far as I know it's stable

what's left is polish and docs

Will go with with your recommendation. Will give 3.1 a shot as early as possible.

asksol: Naive webhook listener in Go that auto-compiles after each Github commit to your Pelican repo https://gist.github.com/gtaylor/6378871

asksol: We use that on http://blog.pathwright.com/. Workflow then just becomes editing the content files and pushing. Can even use Github's built in editor and there's even less involved in cranking out or editing blog posts.

gtaylor: cool :)

oops, seems in 3.1 gevent pool is not shutting down

pretty strange

for step in steps: stop.stop()

all stop calls return, but with gevent it does not exit the for loop

with eventlet it works

I knew there had to be some perk to having chose eventlet aeons ago :)

I'm running celery in django and using the django DB backend for my beat process. if I restart the beat process, will it reset the start time for any scheduled tasks that run every day (for example)

elarson: last_run_at is stored in the database for the DatabaseScheduler

if you change the timezone you will need to reset these manually

asksol: that is what I figured. thank you!

the normal scheduler resets that automatically, but not yet implemented in the DatabaseScheduler

asksol: Is there any way to get some redundancy as far as running multiple celerybeat instances?

asksol: Currently I have to have a "primary" celery worker VM that runs celerybeat+celerycam. Would love for there to be no real distinction between celery worker VMs.

this is django specific, but in my django admin for djcelery, it doesn't show any workers. does that suggest something isn't configured correctly? I have gotten scheduled tasks to run before

ask: https://gist.github.com/diranged/86efd1874c0008... < i sent an email to the mailing list too.. but any ideas on how a task could cause this exception?