Celery in production: Three more years of fixing bugs
ayushshanker.com
Celery in production: Three more years of fixing bugs
1–10 of 63 posts
Re: Celery in production: Three more years of fixing bugs
#2> Supervisor should've killed celery's forked workers once the parent dies. Either it is not reliable or we haven't been able to make this happen in at least a few attempts now.
Use systemd instead of supervisord for misbehaving forking daemons like this. If you set "KillMode=mixed" you get a nice compromise between "signal the parent and give things a configurable grace period to shut themselves down" and "zero risk of orphaned child (or stuck parent) processes being left around after service stop/restart".
Without weighing in on the systemd-vs-other-init debate in general, I do strongly believe that systemd fully obsoletes supervisord. The (slightly) tighter coupling supervisord offers with Python isn't worth the deficient feature set.
Re: Celery in production: Three more years of fixing bugs
#3I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.
Re: Celery in production: Three more years of fixing bugs
#4> Supervisor should've killed celery's forked workers once the parent dies. Either it is not reliable or we haven't been able to make this happen in at least a few attempts now. Use systemd instead of supervisord for misbehaving forking daemons like this. If you set "KillMode=mixed" you get a nice compromise between "signal the parent and give things a configurable grace period to shut themselves down" and "zero risk…
supervisord still has a place in scenarios where you can't or don't want to use the init system. WSL2 and docker containers running multiple processes come to mind.
In most linux environments, this is a non-issue. And some will argue you are using containers wrong if you are running multiple services in a single container, but containers as a reproducible environment and isolation unit is a valid use case (for test/dev environments especially).
Re: Celery in production: Three more years of fixing bugs
#5I love Huey [1]. I switched everything over from Celery to it. It’s so simple it’s a godsend, even supports SQLite queue
Re: Celery in production: Three more years of fixing bugs
#6> Supervisor should've killed celery's forked workers once the parent dies. Either it is not reliable or we haven't been able to make this happen in at least a few attempts now. Use systemd instead of supervisord for misbehaving forking daemons like this. If you set "KillMode=mixed" you get a nice compromise between "signal the parent and give things a configurable grace period to shut themselves down" and "zero risk…
supervisord still has a place in scenarios where you can't or don't want to use the init system. WSL2 and docker containers running multiple processes come to mind. In most linux environments, this is a non-issue. And some will argue you are using containers wrong if you are running multiple services in a single container, but containers as a reproducible environment and isolation unit is a valid use case (for test/d…
Just want to point out there are options other than supervisord. You can even use systemd in a container, though I would avoid it. s6 and runit are both options.
Using something Python-based for this sort of thing makes me slightly nervous.
Re: Celery in production: Three more years of fixing bugs
#7I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.
What would you recommend instead?
Re: Celery in production: Three more years of fixing bugs
#8I ran Celery in many projects in production over the past 10 years; I would not recommend it. It is mostly a constant fight even though it is the first thing most people grab when they have a Django stack.
What would you recommend instead?
I had a good time with dramatiq+apecheduler, much more bare bones and less out of the box, but when something went wrong is was pretty easy to understand and work around.
Re: Celery in production: Three more years of fixing bugs
#9Re: Celery in production: Three more years of fixing bugs
#10I love Huey [1]. I switched everything over from Celery to it. It’s so simple it’s a godsend, even supports SQLite queue [1] https://github.com/coleifer/huey
I implemented this for its Windows support and it's been great.