Docker Compose init怎样回收容器里的子进程

如果一个 Docker Compose 服务只是前台运行一个不会派生子进程的程序，通常不需要额外打开 init。但只要主进程会启动 worker、脚本或其他子进程，就要关注容器内的 PID 1：它是否能接收停止信号，是否会把退出的子进程回收干净。

Compose 提供的直接配置是 init: true。它会在该服务容器内启用一个平台相关的 init 进程，由这个进程负责转发信号并回收子进程。这个开关只作用于服务容器，不会把宿主机改造成另一套 init 系统。

官方地址：https://docs.docker.com/reference/compose-file/services/

先判断服务是否真的会派生子进程

排查时不要先把所有服务都加上 init: true。先看服务的 command、entrypoint 以及应用自身的进程模型。下面三类场景更值得考虑：

• 入口脚本启动后台 worker 后自己继续等待，例如 shell 脚本中出现 &、wait 或多个子命令。
• 应用会派生编译器、任务执行器、定时任务或外部命令，并且这些子进程的生命周期由容器管理。
• 停止容器时，主进程收到信号后退出，但子进程没有及时结束，导致停止时间变长或残留进程状态难以判断。

如果应用本身已经正确作为前台进程运行，并且它明确负责子进程的信号与回收，那么 init: true 不一定带来额外收益。关键是先确定容器内谁是 PID 1，以及谁应该承担回收责任。

在 Compose 服务上开启 init: true

配置是服务级字段，只给确实需要的服务开启即可。下面的例子故意让入口 shell 启动一个后台任务，再等待它结束，用来说明配置位置；示例不是某个真实业务的运行截图。

services:
  worker:
    image: alpine:latest
    # 只对需要管理子进程的服务启用容器内 init。
    init: true
    # 后台任务退出后，前台 shell 才结束，便于观察生命周期。
    command: ["sh", "-c", "sleep 20 & child=$!; wait $child"]

这里的重点不是 sleep，而是 init: true 的位置：它和 image、command 同属于 worker 服务。不要把它写到顶层，也不要把它误当成 Dockerfile 的 ENTRYPOINT 替代品。

如果同一份 Compose 文件还有 web、db 等服务，可按服务的进程模型分别决定。数据库容器是否需要该开关，不能仅凭“它是后台服务”判断，应该结合镜像入口和官方运行方式。

理解 PID 1、信号与子进程回收

容器内的第一个进程是 PID 1。它面对两个容易被忽略的责任：接收容器停止时发来的信号，以及在子进程退出后执行回收。Compose 文档对 init 的定义正是启用一个 init 进程，使其转发信号并回收子进程。

可以把关系简化成下面这样：

容器停止
  └─ stop signal
       └─ PID 1 init
            ├─ 转发信号 → application
            └─ 回收退出 → worker child

这并不意味着应用可以忽略优雅退出。应用仍然需要在收到信号时停止接收新任务、关闭连接并等待必要的子任务结束。init: true 主要补上容器 PID 1 层面的信号转发与回收职责，不能修复应用只在 shell 中吞掉信号、或把长期任务放到错误后台的设计。

用配置检查和退出场景排查

先用 docker compose config 检查 Compose 文件是否能解析，并确认目标服务仍在最终配置中。这个命令只能说明配置模型已被读取，不能单独证明应用已经正确处理了停止信号。

# 在 Compose 项目目录中展开并查看最终配置。
docker compose config

# 只筛选目标服务附近的配置，便于人工确认 init 字段位置。
docker compose config | sed -n '/worker:/,/^[^ ]/p'

然后按一个可重复的停止流程观察现象：

# 以后台方式启动目标服务，避免命令行被服务日志占住。
docker compose up -d worker

# 发送 Compose 停止操作，观察应用和子进程是否按预期退出。
docker compose stop worker

# 清理本例创建的服务，避免遗留容器影响下一次排查。
docker compose rm -f worker

如果配置解析失败，先修复 YAML 层级或字段拼写；如果配置正确但停止仍然拖延，再检查应用是否以前台方式运行、是否捕获了正确的信号，以及入口脚本有没有等待子进程。不要把“命令能启动”直接等同于“进程生命周期正确”。

几个容易混淆的边界

结论

Docker Compose 的 init: true 适合写在会派生子进程、又需要更稳妥处理容器停止流程的具体服务上。它启用容器内 init，重点解决 PID 1 的信号转发和子进程回收；它不是应用进程管理的替代品，也不是宿主机 init 的配置入口。

实际排查可以按这个顺序走：先确认服务是否派生子进程，再在服务级打开 init: true，用 docker compose config 检查字段位置，最后通过停止和清理场景观察应用本身的退出逻辑。

相关问题

所有 Compose 服务都应该开启 init: true 吗？

不必。它是服务级配置，优先给会派生子进程或需要额外 PID 1 管理的服务启用，普通单进程服务可保持默认。

init: true 会替应用处理优雅停机吗？

不会。它帮助转发信号和回收子进程，应用仍要正确接收信号、停止新任务并释放资源。

为什么配置生效了，服务停止仍然很慢？

配置生效不代表应用立即退出。继续检查应用的信号处理、入口脚本是否等待子进程，以及子任务是否有自己的超时或阻塞操作。