dockerd启动需严格按序完成五步初始化：配置加载、日志准备、插件注册、存储驱动挂载、网络初始化；任一跳过或顺序错误将导致容器创建失败、镜像拉取异常等静默故障。

dockerd 进程启动时做了哪些关键初始化

它不是简单跑个 main() 就完事，核心是按顺序完成配置加载、日志准备、插件注册、存储驱动挂载、网络初始化这五步。跳过或顺序错会导致后续容器无法创建、镜像拉不下来、docker ps 报空指针等静默失败。

常见错误现象：dockerd 启动后立即退出，日志里只有一行 failed to start daemon: error initializing graphdriver: driver not supported；或者 docker info 显示 Storage Driver: overlay2 但实际写入失败——大概率是存储驱动初始化阶段没校验宿主机内核支持就强行挂载了。

• 配置加载优先读 /etc/docker/daemon.json，再 fallback 到命令行参数；若两者冲突（比如都设了 data-root），以配置文件为准
• 日志初始化必须早于所有子模块，否则 containerd 子进程崩溃时无迹可寻
• graphdriver 初始化前会调用 graphdriver.New() 做 probe，但部分驱动（如 zfs）probe 不够严格，得靠后续 graphdriver.Init() 才真正校验权限和路径可写

为什么 dockerd 启动卡在 “starting containerd”

这不是 containerd 自身问题，而是 dockerd 在等待它完成 handshake：先 fork 出 containerd 进程，再通过 unix socket 连过去发一个 version 请求，超时默认 2 分钟。一旦失败，dockerd 就 panic 退出，不会重试。

典型场景：宿主机启用了 SELinux 或 AppArmor，但没给 containerd 的 socket 路径（默认 /run/containerd/containerd.sock）打标签；或者 /run/containerd 目录被其他进程占用、权限为 0700 且属主不是 root:docker。

• 检查 containerd 是否真在运行：ps aux | grep containerd，注意看是不是 dockerd fork 出来的那个（PPID 是 dockerd 的 PID）
• 手动连 socket 测试：sudo ctr --address /run/containerd/containerd.sock version，报 connection refused 就说明 handshake 根本没开始
• 临时关闭安全模块验证：sudo setenforce 0（仅测试），若恢复启动则需补 semanage fcontext 规则

initContainer 和 initProcess 的区别在哪

这两个词在 dockerd 源码里根本不存在——它是 Kubernetes 的概念。Docker 本身没有 init container 机制，它的容器初始化逻辑全压在 containerd-shim 启动时的 InitProcess 上，也就是容器 PID=1 的那个进程。

容易踩的坑是误以为加了 --init 参数就等于开了 init container：其实只是让 runc 启动时多套一层 tini（或指定的二进制），用来收僵尸进程、转发信号。它不隔离、不单独调度、不共享网络命名空间，和 K8s 的 init container 完全是两回事。

• --init 实际插入的是 runc 的 --init 参数，最终生成的 config.json 里会多一个 process.args 数组，首项变成 /dev/init
• 如果镜像里已有 ENTRYPOINT ["/sbin/myinit"]，再加 --init 会导致双重 init，第二个 init 收不到第一个的子进程，僵尸照常堆积
• docker run --init 对 Windows 容器无效，因为 runc 不处理 Windows 的服务管理模型

如何确认 dockerd 是否完成了全部初始化

不能只看进程是否存在或端口是否监听，要查 dockerd 内部状态机是否走到 ready。最直接的方式是发一个轻量 health check 请求：curl -s --unix-socket /var/run/docker.sock http://./_ping，返回 OK 且 HTTP 状态码为 200，才代表初始化完成并进入服务态。

很多自动化脚本用 systemctl is-active docker 或 pgrep dockerd 判断启动成功，结果在高负载机器上频繁失败——因为 dockerd 进程已存在，但内部还在加载镜像层、扫描 volume、同步 swarm node 状态，此时 docker ps 仍会 block 或报 Cannot connect to the Docker daemon。

• 生产环境建议用 timeout 60s bash -c 'until curl -s --unix-socket /var/run/docker.sock http://./_ping &>/dev/null; do sleep 1; done' 做启动等待
• _ping 接口不触发任何后台任务，也不依赖 storage driver 就绪，是唯一能反映“服务可用”的指标
• 如果 _ping 返回 503，说明 dockerd 卡在某个模块初始化中（比如 overlay2 正在做 fsync），需要查 journalctl -u docker -n 100 最后几行