使用docker-compose时Celery出现僵尸线程问题求助

问题根源：PID 1进程的子进程回收机制差异 #

这问题核心出在容器启动时的PID 1进程行为不同，以及bash -c作为PID 1时的局限性：

1. docker-compose up启动时的僵尸进程成因
   当你在docker-compose.yml里用command: bash -c "celery ..."启动服务时，容器的PID 1进程是bash。而bash默认不会主动监听并处理SIGCHLD信号——这个信号是用来通知父进程子进程已经退出，需要回收其资源的。
   你的Celery配置了--max-tasks-per-child=1，意味着每个任务完成后worker子进程都会重启；再加上任务里用到的Selenium/webdriver本身也会启动子进程。这些子进程退出后，作为父进程的bash（PID1）不会去回收它们的退出状态，导致这些进程变成僵尸（defunct）并堆积。

2. docker-compose run手动执行无僵尸的原因
   你手动执行的命令加了--detach，这会让Celery worker后台运行，此时Celery会成为独立的会话进程，它的父进程可能是容器内的init进程（如果镜像自带的话），而init进程的核心职责之一就是回收退出的子进程。另外，--detach参数会让Celery自身接管子进程的生命周期管理，避免僵尸进程产生。

3. 改用entrypoint解决问题的逻辑
   当你用entrypoint直接启动Celery（不管是脚本还是直接命令），本质上是让Celery（或者脚本进程）成为容器的PID 1：

   • 如果是直接用entrypoint: celery ...，Celery进程就是PID1，它自身的worker管理机制会主动回收子进程，同时也会正确处理SIGCHLD信号；
   • 你用shell脚本作为entrypoint时，脚本是PID1，Celery是它的子进程，但Celery自身会负责回收自己启动的子进程（比如webdriver、worker子进程），不会让脚本去处理，因此不会产生僵尸。

额外建议 #

如果用shell脚本作为entrypoint，建议在脚本里用exec命令启动Celery：

#!/bin/sh
exec celery -A tasks worker --concurrency=1 --max-tasks-per-child=1 -l info -Q loonbeat

这样exec会让Celery直接替换shell脚本进程成为PID1，彻底避免中间shell进程带来的潜在问题，是更规范的容器启动方式。

内容的提问来源于stack exchange，提问作者Andy Su