Docker容器中保持后台进程持续运行的问题排查

核心问题分析 #

Docker容器的生命周期完全绑定主进程——当主进程结束，容器就会直接退出。你的./restart命令在宿主机环境会把游戏进程后台运行，这导致容器内的主进程（./restart脚本）执行完毕就终止，容器自然跟着退出。而用tail -f /dev/null只是强行维持容器存活，但没有让游戏进程成为容器的主进程，所以只能手动启动生效。

具体解决方法 #

方法1：让游戏进程直接作为容器主进程

首先排查./restart脚本的逻辑——它大概率是通过nohup、&这类参数把游戏进程后台化。你需要：

• 找到游戏的前台启动命令（比如脚本里实际启动游戏的那行，去掉后台运行参数）
• 修改Dockerfile，将这个前台命令设为容器的启动命令：

  # 假设游戏前台启动命令为./game-server
  CMD ["./game-server"]
  

• 如果必须保留./restart脚本，直接修改脚本，移除所有让进程后台运行的配置（比如删掉行尾的&，去掉nohup前缀）

方法2：用exec让脚本子进程成为主进程

如果无法修改./restart脚本，启动时用exec命令替换当前shell进程，让游戏进程成为容器的主进程：

• 修改Dockerfile的启动命令：

  CMD ["sh", "-c", "exec ./restart"]
  

• 或者启动容器时直接指定命令：

  docker run -d --name game-container your-image sh -c "exec ./restart"
  

方法3：用tini管理进程（适配复杂场景）

如果游戏有多个子进程，或者需要正确处理终止信号（如CTRL+C），可以用tini作为容器的init进程：

1. 在Dockerfile中安装tini（以Debian/Ubuntu基础镜像为例）：

   RUN apt-get update && apt-get install -y --no-install-recommends tini
   

2. 将tini设为ENTRYPOINT，再启动游戏：

   ENTRYPOINT ["tini", "--"]
   CMD ["./restart"]
   

tini会接管容器的进程管理，确保游戏进程始终作为主进程运行，同时正确处理信号传递。

验证方式 #

• 启动容器后，用docker logs game-container查看日志，确认游戏进程是否正常启动
• 用docker top game-container查看容器内进程列表，确保主进程是游戏相关进程，而非tail或shell

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