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，注意看是不是dockerdfork 出来的那个（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最后几行
