A pretty straightforward question, maybe –
I often see a celery task process running on my system that I cannot find when I use celery.task.control.inspect()‘s active() method. Often this process will be running for hours, and I worry that it’s a zombie of some sort. Usually it’s using up a lot of memory, too.
Is there a way to look up a task by linux pid? Does celery or the AMPQ result backend save that?
If not, any other way to figure out which particular task is the one that’s sitting around eating up memory?
—- updated:
What can I do when active() tells me that there are no tasks running on a particular box, but the box’s memory is in full use, and htop is showing that these worker pool threads are the ones using it, but at the same time using 0% CPU? if it turns out this is related to some quirk of my current rackspace setup and nobody can answer, I’ll still accept Loren’s.
Thanks~
I’m going to make the assumption that by ‘task’ you mean ‘worker’. The question would make little sense otherwise.
For some context it’s important to understand the process hierarchy of Celery worker pools. A worker pool is a group of worker processes (or threads) that share the same configuration (process messages of the same set of queues, etc.). Each pool has a single parent process that manages the pool. This process controls how many child workers are forked and is responsible for forking replacement children when children die. The parent process is the only process bound to AMQP and the children ingest and process tasks from the parent via IPC. The parent process itself does not actually process (run) any tasks.
Additionally, and towards an answer to your question, the parent process is the process responsible for responding to your Celery inspect broadcasts, and the PIDs listed as workers in the pool are only the child workers. The parent PID is not included.
If you’re starting the Celery daemon using the –pidfile command-line parameter, that file will contain the PID of the parent process and you should be able to cross-reference that PID with the process you’re referring to determine if it is in fact a pool parent process. If you’re using Celery multi to start multiple instances (multiple worker pools) then by default PID files should be located in the directory from which you invoked Celery multi. If you’re not using either of these means to start Celery try using one of them to verify that the process isn’t a zombie and is in fact simply a parent.