容器 19：一次 run 在哪一步变成 exec
“docker run 成功了”最多说明某条客户端请求获得了响应，不保证 probe-app 能够接收真实业务请求。先把13 的镜像制品、18 的 content/task和17 的 create/start沿时间摆成一条链，再讨论不同故障落在哪一层。
一次请求的可能路径
用户端请求 daemon 创建或启动容器；daemon 对镜像引用做解析或拉取，准备快照与运行配置；下游运行时创建对应 Linux 进程并执行入口。是否通过 containerd、shim、哪一种 OCI runtime 由本机版本与配置决定，不能给出未经版本验证的唯一函数调用栈。进程 exec 成功之后，应用还可能解析参数失败、只监听 loopback 或尚未就绪。把“客户端返回”、“daemon 对象创建”、“宿主进程执行”、“HTTP /ready=200”各自作为检查点，才能说清哪个阶段失败。
正常案例要求同一次构建的 image digest 贯穿 docker inspect、runtime ID、宿主 PID、namespace inode 和请求日志，按时间排序保存不同组件的事件；失败案例把探针入口命令改为不存在路径，只改自建镜像或容器，预期镜像可拉取而 exec 失败，不能描述成下载错误。附件列出跟踪字段与清理，源码包沿用可信探针，避免把完全不同应用的日志拼成一条链。
当前云端没有 Docker/containerd，也就没有选定版本源码可核对的 daemon 调用路径。本文仅陈述规范/文档允许的分层关系，真实事件链及错误案例均 NOT_RUN；切勿把 00 中普通进程的 /identity 冒充 Docker 进程证据。
| 现象 | 从哪层开始排查 | 缺什么证据不能定论 |
|---|---|---|
| pull 成功但 run 失败 | config、snapshot、exec 错误 | 没有宿主 PID 不等于网络问题 |
| run 返回但业务 503 | 进程/监听/应用 ready | 缺业务请求不能判定成功 |
| 只有容器 ID | 对应 task PID、镜像 digest | 不能还原调用链 |
练习
- 先预测入口路径不存在时，镜像下载、容器创建、进程执行三个阶段会在哪一步出现首个可见失败；在专用 VM 保留对应返回码和原始日志。
- 预测 probe-app 设
--ready-delay 10与入口立即异常退出的/health、/ready及进程状态差别，逐项验证不把 503 当 exec 失败。
上一篇：18：containerd 对象；下一篇：20：rootless。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 09：组合隔离机制时启动和清理的顺序
前八篇分别讨论进程、namespace、身份、资源和权限。如果只把它们列在命令行上，很容易遗漏“父进程何时写映射”“谁等待子进程”“初始化失败后对象如何退出”。这篇用一个受限教学启动器展示顺序，并明确它没有实现的隔离，避免误当成生产容器。 一个可核查的局部链路 源码共用源码包内的 teaching_launcher.c 固定执行同目录内自编译的 process_probe，没有接受用户指定的命令行、镜像或任意路径。启动器记录外侧 UID/GID，先 unshare(CLONE_NEWUSER)，将内部 UID/GID 0 映射到原外侧身份；在写 GID 映射之前向 setgroups 写 deny。随后建立新的 UTS、IPC namespace，在私有 UTS 中设置测试 hostname。fork 后只有子进程 exec 自编程序，父进程 waitpid 并返回子进程状态。设置顺序的核心是写映射时“当前进程处于哪个 namespace”，而不是把一串 unshare 选项当成 magic flag。 从当前源码画出真实的控制流 第一步在外侧读取实际 UID/GID；这两个数字...
2026-10-01
容器 34：冷启动时间花在哪一段
拿一条从 docker run 到终端提示的总耗时，无法推断是拉取慢、快照准备慢、进程启动慢还是应用就绪慢。先定义测量的边界与可关联的对象，然后谈数值。 先写实验设计，后写结论 同一 probe-app 固定 image digest、节点 CPU 架构、内核与运行时版本，在专用 VM 上分冷缓存与热缓存两组。时间戳分别落在开始拉取、manifest/layer 验证结束、本机解包与 snapshot 准备结束、OCI create/start、进程首条日志、/ready=200。对同一 ID 记录事件时钟来源，跨组件不能把不同机器的墙钟未经校准就做相减。预先确定预热次数、重复次数、并发、输入大小和失败率，报告每段延迟分布而不是一次的总值；把镜像缓存和应用缓存状态同时记录。 边界例是第二轮 pull 因内容已在本地而很快，服务却因独立的就绪延迟仍返回 503。把这两段之和直接叫“镜像启动慢”会误判优化目标。一次用户请求成功还可能发生在 ready 之前或之后，需用相同 readiness 条件比较。实验变量表和有界探针保证输入一致；本机无构建器、运行时或集群，所有时间分段、重复数...
2026-10-01
容器 18：containerd 管的是镜像、任务还是进程
17 的 OCI runtime关注单个 bundle 的 create/start/delete；更上一层还要保存镜像内容、展开快照、管理任务生命周期。containerd 的 content store、snapshotter、container metadata、task 和 shim 并不是五个同义词。它们各自关联不同对象，故一个动作“删镜像”与“停 task”不应被写成相同效果。 内容引用与进程引用分开 按 containerd 的 Runtime V2 文档，运行时 shim 承担与任务相关的运行时集成，OCI runtime 可用于创建实际进程。content store 保存内容寻址的字节；snapshotter 为运行准备文件系统视图；task 对应运行中的进程生命周期。containerd 的 namespace 是其 API/元数据隔离维度，不能拿它代替 Linux namespace inode，更不能把它当 Kubernetes Namespace 的定义。一个镜像引用可以消失而正在运行的进程仍存在；停止任务也不会自动清空 registry 的原始镜像。...
2026-10-01
容器 21：停止、重启和日志分别由谁负责
03解释了 PID 1 的信号与回收，18区分 task 与 content。现在讨论停止与恢复：`stop` 是请求进程退出的流程，`restart` 是另一次启动动作，日志是 FD 输出经采集路径形成的证据；三个动作不自动互相保证。 时间窗口需要观测 通常运行时先发终止信号，留宽限期等待程序自己处理、回收子进程并结束；超时后可强制终止。应用若安装 handler 却不结束在途请求，或 shell 没有转发信号，即使运行时遵守流程也可能直到超时。比较宽限期要保存发送时刻、程序收到的事件、最后一条业务响应、实际退出原因，单看 shell 的 137 不能推出是超时强制杀还是内存 OOM。 日志链也有不同持有者：程序写 stdout/stderr FD、shim/daemon 依配置收集、日志驱动再存储或转发。程序未 flush 缓冲、进程强制终止或采集器重启都可能造成末尾日志缺口；不能以运行时提示“容器 restarted”证明请求、日志和写盘数据已经恢复。daemon 的重启行为依运行时、shim、配置及版本而异，必须在专用实验 daemon 里验证，禁止重启共享宿主服务。 正...
2026-10-01
容器 E03：eBPF 事件属于哪一个容器
eBPF 程序在内核钩子看到的是事件时刻的进程和内核对象，不会自动附赠“这一定属于 Pod A”的可靠标签。31 的身份链需要把 PID、cgroup、namespace inode、容器 ID 与 Pod UID 在时间窗口内对齐，尤其要考虑容器退出后 PID 被重用。 先判定事件是什么 选择一个自编 probe-app 可控的事件，例如打开自己的状态文件；在 eBPF 程序里采集时间戳、PID/TGID 与 cgroup 标识，在用户态按同一时刻运行时映射关联到容器 ID、Pod UID。权限、内核 BPF 功能和事件丢失都应写进记录。若只装了探针、打印几行带 PID 的事件，却没有证明进程当时属于哪一代容器，就仍是错误归因风险。访问 /proc 获取当前 PID 的属性只能证明读取时的状态，不保证事件发生时该 PID 还属于同一进程。 正例在独立 kind VM 中对自有探针触发一次文件打开，核对事件、实际 PID、cgroup/namespace 与 Pod UID；边界例立即重建同名 Pod，检验新旧事件能否正确分组，即使宿主 PID 以后复用也不能并为一条轨迹。身份字...
2026-05-24
cgroup memory：内存从全局资源变成局部预算
上一篇讲了 SLUB 如何在页之上管理小对象的分配。到此为止，所有讨论都假设一个全局的内存资源池——进程共享同一组物理页，回收和 OOM 是全局决策。容器化环境打破了这个假设：一个容器不应该消耗完整机器的内存，它的 OOM 不应该波及其他容器。 核心问题可以压成一句话： memcg 把全局 VM 策略投影到层级资源边界里，使回收、统计和 OOM 都带上 cgroup 语义。 问题从哪里来 传统 Linux 内存管理是全局视角：所有进程共享物理内存，kswapd 按全局水位线回收，OOM killer 从全局选 victim。这在单租户系统上没问题，但在多租户场景（容器、虚拟化、共享主机）上不够： 第一，隔离性缺失。一个行为异常的容器可以消耗所有可用内存，触发全局 OOM，导致无关容器的进程被杀。 第二，资源可预测性缺失。一个容器无法知道自己"还能用多少内存"——这取决于其他容器当前的使用情况。 第三，统计粒度缺失。管理员无法回答"这个服务用了多少内存"——/proc/meminfo 只有全局数据。 cgroup memory cont...