ragflow icon indicating copy to clipboard operation
ragflow copied to clipboard

[Bug]: The Docker container stopped, but the process is still running.

Open weynechen opened this issue 2 weeks ago • 2 comments

Self Checks

  • [x] I have searched for existing issues search for existing issues, including closed ones.
  • [x] I confirm that I am using English to submit this report (Language Policy).
  • [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
  • [x] Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

ba71160b

RAGFlow image version

v0.22.0

Other environment information


Actual behavior

问题现象: docker compose 启动, 电脑重启,使用docker ps 看不到容器在运行。但使用ps aux 能看到 ragflow_server 等进程在跑。从log日志看,ragflow不停的在重启。从而导致CPU占用率飙升,风扇狂转。

问题表现: docker ps 不显示 进程还在 PPID 指向 container 的 shim 进程会自动重启 kill 不断换 PID docker restart 无效

Image Image

Expected behavior

进程应该随docker stop而停止

Steps to reproduce

#### 问题现象:
docker compose 启动, 电脑重启,使用docker ps 看不到容器在运行。但使用ps aux 能看到 ragflow_server 等进程在跑。从log日志看,ragflow不停的在重启。从而导致CPU占用率飙升,风扇狂转。

### 问题表现:
docker ps 不显示
进程还在
PPID 指向 container 的 shim
进程会自动重启
kill 不断换 PID
docker restart 无效


#### 解决方案:
1. 把entrypoint.sh删除
2. sudo pkill -f rag/svr
sudo pkill -f ragflow_server
sudo pkill -f entrypoint.sh
3. 重启docker

#### 问题原因:
Docker 的“僵尸容器失控”。entrypoint.sh 中:
while true; do
    "$PY" api/ragflow_server.py &
    wait;
    sleep 1;
done &

将ragflow_server.py 放到后台,这会让 ragflow_server.py 脱离 PID1,PID=1 的 bash 进程认为“任务已完成”,Docker 认为容器退出,但后台的 python 继续活着!

#### 建议方案:
使用 supervisord , 用 supervisor 管理 ragflow_server、task_executor、nginx , 不再需要任何 while true, 不再需要后台 &。

Additional information

No response

weynechen avatar Dec 09 '25 09:12 weynechen

Hi @weynechen! I'm Dosu and I’m helping the ragflow team.

This issue is caused by the current entrypoint.sh script, which starts ragflow_server.py and other services in a backgrounded while-true loop. This causes the main process (PID 1) in the container to exit while the Python processes keep running in the background, so Docker thinks the container is stopped but the processes remain as orphans on the host. This is why docker ps shows nothing, but ps aux shows ragflow_server and related processes still running, and why killing them just spawns new PIDs and docker restart has no effect.

The codebase as of your version (v0.22.0, commit ba71160b) still uses this pattern—there is no supervisord or equivalent process manager in use, and the official upgrade guide does not mention a fix or migration for this issue. The recommended solution is to remove entrypoint.sh, kill any lingering ragflow_server or related processes, restart Docker, and switch to using supervisord (or a similar process manager) to manage all services in the container. This ensures that when the container stops, all processes are properly terminated and you avoid orphaned processes and resource leaks.

You can see the problematic pattern and lack of supervisord in the current entrypoint.sh script here. No relevant pull requests or documentation changes address this yet.

If you need a step-by-step workaround:

  1. Stop all containers and remove entrypoint.sh from your image.
  2. Kill any lingering ragflow_server, sync_data_source, or related processes on the host.
  3. Restart Docker.
  4. Use supervisord or another process manager to launch and manage all required services in the container, without backgrounding or while-true loops.

This will ensure proper process lifecycle management and prevent this issue from recurring.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

dosubot[bot] avatar Dec 09 '25 09:12 dosubot[bot]

How about this? sudo systemctl stop docker

KevinHuSh avatar Dec 10 '25 03:12 KevinHuSh