docker daemon“假死”是线程级死锁所致，表现为docker ps卡住、api无响应但进程存活，根因多为cgroup v2 setup或namespace初始化阶段的goroutine阻塞；需通过sigusr1获取goroutine堆栈定位锁竞争点，并结合ebpf追踪锁持有者与阻塞路径，典型诱因包括cgroup_mutex争抢、nsproxy_mutex竞争及shim socket写锁拖累。
Docker Daemon 假死不等于崩溃退出，它常表现为 docker ps 卡住、API 无响应、但进程仍在（ps aux | grep dockerd 可见），此时 线程级死锁 是典型诱因——尤其在边缘设备或高并发容器创建场景下，runc create 链路中 cgroup v2 setup 或 namespace 初始化阶段的锁竞争极易引发 goroutine 阻塞，导致主线程无法响应请求。
要定位这类“假死”，关键不是看 crash dump（daemon 通常不会生成 core 文件），而是抓取 实时线程状态快照 + goroutine 堆栈追踪，并聚焦调度链路中的同步原语阻塞点。
一、确认 daemon 是否真“假死”而非彻底崩溃
先排除 OOM、磁盘满、socket 断连等表层问题：
# 检查进程是否存活且无响应 sudo kill -0 $(pgrep dockerd) && echo "alive" || echo "dead" # 测试 API 是否响应（超时设为 3 秒） timeout 3s curl -f http://unix:///var/run/docker.sock/v1.43/info > /dev/null 2>&1 && echo "responsive" || echo "unresponsive" # 查看 dockerd 进程的线程数是否异常膨胀（死锁常伴随大量 goroutine 阻塞） ps -o pid,tid,nlwp,comm -T $(pgrep dockerd) | tail -n +2 | wc -l # 若 > 500，需警惕
若确认“活着但卡住”，进入下一步。
二、获取 goroutine 堆栈快照（核心诊断动作）
Docker daemon 是 Go 程序，支持通过 SIGUSR1 触发 runtime stack dump，输出所有 goroutine 当前调用栈到日志：
# 向 dockerd 主进程发送信号（注意：必须是主进程 PID，非 systemd wrapper） sudo kill -USR1 $(pgrep -f "dockerd.*--config-file" | head -n1) # 立即查看最新堆栈（默认输出到 journald） journalctl -u docker.service --since "30 seconds ago" -n 200 | grep -A 20 -B 5 "goroutine [0-9]*.*running\|goroutine [0-9]*.*locked"
重点关注以下模式：
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 大量 goroutine 停留在
sync.(*Mutex).Lock、sync.(*RWMutex).RLock或runtime.gopark - 多个 goroutine 在
github.com/containerd/containerd/services/tasks.(*localTasks).Create或github.com/moby/moby/daemon.(*Daemon).ContainerCreate中阻塞 - 出现
waiting for runtime.gopark且调用链含cgroupv2.(*manager).Apply或nsenter.NsEnter
✅ 示例线索：
goroutine 1234 [semacquire, 120 minutes]:sync.runtime_SemacquireMutex(0x...)sync.(*Mutex).Lock(...)github.com/containerd/containerd/pkg/cgroups.(*v2).Update(...)
→ 表明 cgroup v2 更新被某 goroutine 长期持有锁，其他创建请求全部排队等待。
三、结合 eBPF 追踪锁持有者与阻塞路径（精准定位根因）
仅靠堆栈难以判断谁持锁、谁等锁。需用 eBPF 工具观测实际锁竞争：
# 安装并运行 lockstat（基于 bpftrace）
sudo bpftrace -e '
kprobe:mutex_lock {
@mutex[comm, ustack] = count();
}
kretprobe:mutex_lock /@holding[tid] == 0/ {
@holding[tid] = nsecs;
}
kretprobe:mutex_unlock {
$delta = nsecs - @holding[tid];
@lock_time[comm, ustack] = hist($delta);
delete(@holding[tid]);
}
' 2>/dev/null | head -50
更实用的是复用已验证脚本（如 Docker 27 调度链路分析中提到的 runc exec 时延追踪）：
# 监控 runc 创建过程中的阻塞点（直接关联高频创建死锁） sudo ./trace-runc-create.py --duration 60 # 输出含锁等待、namespace setup 耗时
常见死锁路径包括：
-
cgroup v2 controller 同步锁冲突：多个
runc create并发调用cgroup2.Apply()，而内核 cgroup v2 的cgroup_mutex在低配 ARM 设备上争抢激烈 -
namespace 克隆锁（
nsproxy）竞争：clone(CLONE_NEWNS|CLONE_NEWUTS|...)调用被nsproxy_mutex阻塞，尤其在 overlay2 + d_type=yes 检查频繁时 -
containerd-shim 与 dockerd 间 Unix socket 写锁：当大量容器同时启动，shim 回写状态消息阻塞在
unix.(*netFD).Write，反向拖垮 dockerd 主循环
四、临时缓解与配置固化建议
确认死锁模式后，立即生效的规避措施：
-
限制并发创建速率：在 daemon.json 中启用
max-concurrent-downloads: 3（已知可降低 shim 压力），并配合应用层限流（如 client 端加令牌桶） -
降级 cgroup 版本：国产 OS 或旧内核下，强制使用 cgroup v1（
{"exec-opts": ["native.cgroupdriver=cgroupfs"]}） -
禁用非必要命名空间隔离：对轻量容器，启动时加
--security-opt=unmask=/proc/sys+--cap-drop=ALL，减少 ns 克隆开销 -
升级 containerd + runc 组合：Docker 24.0+ 默认 bundle 中 containerd v1.7.13+ 修复了
tasks.Create中的 mutex 持有时间过长问题
不复杂但容易忽略：假死故障极少源于代码 BUG，多由 硬件资源约束 × 内核特性 × 配置未对齐 三重叠加所致。堆栈和 eBPF 不是用来“找 bug”，而是帮你看清哪条链路在真实世界里绷到了临界点。
