Docker 容器内 systemctl 不可用：init 缺失与多进程管理的取舍

发布时间：2026-09-24 12:31 更新时间：2026-09-24 12:31 阅读量：0

很多站长第一次在容器里敲 systemctl restart nginx，会看到一条让人摸不着头脑的报错：Failed to connect to bus: No such file or directory。这不是镜像坏了，也不是权限不够，而是容器里根本没有 init 进程，也没有 systemd 在监听那个 D-Bus 总线。理解这一点，才能决定容器里的多进程到底该怎么管。

为什么容器里 systemctl 用不了

传统 Linux 启动时，内核拉起 PID 1，通常是 systemd，由它去读 unit、拉起服务、管理 D-Bus。容器是内核用 namespace 隔离出来的进程视图，镜像里默认只跑你指定的那个命令，它就是容器内的 PID 1。精简镜像（alpine、debian-slim、各种 distroless）里压根没装 systemd，自然没有 /run/systemd/system，也没有 D-Bus socket，systemctl 连总线都连不上。

换句话说，systemctl 管理的是宿主机的服务生命周期，而容器本身就是一个被管理的进程。把 systemd 塞进容器（所谓的 systemd-in-container）不是不能做，需要 privileged、挂载 cgroup、开放 /sys/fs/cgroup，代价是容器和宿主机边界变得模糊，也失去了容器轻量的意义。多数建站与运维场景下，更推荐换一种思路：让容器自己负责它内部那几个进程。

先确认一下当前容器的 PID 1 是谁，这条命令在排查时很有用：

docker run --rm alpine sh -c 'echo PID1=$PPID; ps -o pid,ppid,comm -p 1'
进入正在运行的容器后也可以直接看
docker exec -it 容器名 ps -o pid,ppid,comm -p 1

如果看到 PID 1 是你的应用进程（nginx、java、python 之类），那就说明这个容器没有任何服务管理器，多进程需要自己安排。

方案一：用 supervisor 管多个进程

supervisor 是一个 Python 写的进程管理工具，常被用来在同一个容器里同时跑 nginx + php-fpm、或者应用 + 日志采集。它的优点是有统一的配置文件、能自动拉起挂掉的子进程、能把子进程日志汇总到 stdout。安装方式以基础镜像为准，Debian/Ubuntu 系大致如下：

apt-get update && apt-get install -y supervisor
mkdir -p /etc/supervisor/conf.d
配置文件示例：/etc/supervisor/conf.d/app.conf

一份典型配置长这样，nodaemon=true 是关键，让 supervisor 自己以前台方式运行，成为容器的 PID 1：

[supervisord]
nodaemon=true
user=root
logfile=/dev/null
logfile_maxbytes=0

[program:nginx]
command=/usr/sbin/nginx -g "daemon off;"
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:php-fpm]
command=/usr/sbin/php-fpm8.2 -F
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

Dockerfile 里把入口指过去即可：CMD ["/usr/bin/supervisord","-c","/etc/supervisor/supervisord.conf"]。要注意两个坑：一是子进程的日志必须重定向到 /dev/stdout、/dev/stderr，否则 docker logs 看不到东西；二是 supervisor 转发信号的能力有限，docker stop 时它给子进程发的是可配置的 stopsignal，默认 TERM，如果应用不响应 TERM 会被强杀，配置里最好显式声明 stopsignal=TERM 并留出 stopwaitsecs。具体行为以 supervisor 官方文档为准。

方案二：entrypoint 脚本自己管

如果只是两个进程，用 Bash 写一个 entrypoint 脚本往往比引入 supervisor 更轻。核心要点：脚本用 exec 让最后一个进程接管 PID 1，或者用 trap 转发信号，同时用 wait -n 监听子进程退出。

#!/usr/bin/env bash
set -euo pipefail

后台拉起第一个进程
/usr/sbin/php-fpm8.2 -F &
php_pid=$!

用 exec 让 nginx 成为 PID 1，信号可以直接到达
exec /usr/sbin/nginx -g "daemon off;"

这种做法简单直接，但有个明显限制：nginx 成为 PID 1 之后，php-fpm 退出它不会感知，容器不会自动重启。想要更完整的编排，可以用 trap 加 wait：

#!/usr/bin/env bash
set -euo pipefail

stop() {
  kill -TERM "$php_pid" 2>/dev/null || true
  wait "$php_pid" 2>/dev/null || true
  exit 0
}
trap stop TERM INT

/usr/sbin/php-fpm8.2 -F &
php_pid=$!
/usr/sbin/nginx -g "daemon off;" &
nginx_pid=$!

任意一个退出就整体退出，交由 Docker 重启策略处理
wait -n "$php_pid" "$nginx_pid"

这套写法的好处是依赖极少，坏处是进程数量一多、重启策略一复杂，脚本会迅速变成难维护的泥球。进程超过三个、或者需要精细的启动顺序与退避重启时，supervisor 或者干脆拆成多个容器会更省心。

怎么选：几个判断标准

第一看进程数量与耦合度。单进程应用（大多数 Go、Node、Java 服务）根本不需要进程管理器，直接让应用当 PID 1 就好。第二看是否需要同时暴露两个服务，比如 nginx 加 php-fpm，这时 supervisor 或 entrypoint 都行，前者配置化、后者零依赖。第三看日志与信号，无论哪种方案，都要保证子进程日志进 stdout、主进程能收到 SIGTERM 并优雅退出，否则 docker stop 会等满 10 秒再 SIGKILL，滚动更新时容易中断请求。

更现代的思路是一个容器只跑一个进程，用 docker compose 把 nginx、php、数据库拆开，各自独立重启、独立扩缩容，排障也清晰。容器内塞多进程属于历史包袱或特殊场景下的折中，能用拆分解决就别用 supervisor 硬扛。

最后给一个可执行的验证习惯：改完 entrypoint 或 supervisor 配置后，用 docker run 前台跑一次，观察 docker logs 是否有子进程输出，再执行 docker stop 计时，确认退出是否在几秒内完成。把这两步做熟，容器里的多进程管理就不会再靠猜。

继续阅读