本文详解如何基于 libcontainer 实现类似 docker run 与 docker exec 的功能，重点解决在已运行容器内安全、并发地启动新进程的核心问题，并提供可验证的代码示例与关键注意事项。
本文详解如何基于 libcontainer 实现类似 `docker run` 与 `docker exec` 的功能，重点解决在已运行容器内安全、并发地启动新进程的核心问题，并提供可验证的代码示例与关键注意事项。
在容器运行时开发中，libcontainer（runc 的底层容器执行引擎）原生支持在同一个容器命名空间内启动多个进程——这正是 docker exec 的技术基础。但与 docker run 不同，exec 并非重启容器，而是复用现有 cgroup、mount、network、PID 等命名空间，仅注入新进程。若你的 Exec 函数出现“等待主进程退出”或内存持续增长，通常源于以下三类典型错误：TTY 生命周期管理失当、信号处理器重复注册、标准流未正确隔离。
✅ 正确实现 Exec 的核心原则
复用容器状态，不重建命名空间
container.Start(process) 必须作用于已创建且正在运行的容器实例（即 f.CreateContainer() 后未被销毁），而非新建容器。确保 container.Status() 返回 libcontainer.Running。TTY 必须独立初始化，且不可复用主进程 TTY
主进程的 TTY 是独占资源；exec 进程需创建专属 TTY 实例（如通过 pty.StartWithArgs 或 newTty(true, process, uid)），并确保其生命周期严格绑定当前 exec 调用（defer tty.Close() 正确放置）。信号处理需按进程粒度隔离
每个 exec 进程应拥有独立 SignalHandler 实例。共享 handler 会导致信号转发冲突、goroutine 泄漏，最终引发内存暴涨（你观察到的 5–7 次后 100% 内存占用即典型表现）。-
I/O 流必须显式重定向，禁用继承
错误示例中 process.Stdin = os.Stdin 将宿主机 stdin 直接注入容器，极易导致阻塞或竞态。正确做法是：- 使用 io.Pipe() 构建双向通道；
- 通过 tty.SetStdin(pipeReader) 等方式桥接；
- 避免 defer 关闭写端前读端已退出。
✅ 可运行的 Exec 实现（精简版）
func Exec(container libcontainer.Container, spec specs.Process, onData func([]byte), onErr func(error)) (int, error) {
// 1. 创建新进程对象（非复用主进程）
process := &libcontainer.Process{
Args: spec.Args,
Env: spec.Env,
Cwd: spec.Cwd,
UserID: uint32(spec.User.UID),
Terminal: spec.Terminal,
}
// 2. 初始化专属 TTY（关键！）
rootUID, err := container.Config().HostUID()
if err != nil {
return -1, fmt.Errorf("get host UID: %w", err)
}
tty, err := newTty(spec.Terminal, process, rootUID)
if err != nil {
return -1, fmt.Errorf("create tty: %w", err)
}
defer tty.Close() // 确保在此处 defer
// 3. 创建独立信号处理器
sigHandler := NewSignalHandler(tty)
defer sigHandler.Close() // 每次 exec 独立 handler
// 4. 安全重定向 I/O（以 stdout 为例）
stdoutPipeR, stdoutPipeW := io.Pipe()
process.Stdout = stdoutPipeW
process.Stderr = stdoutPipeW
// 5. 启动进程（非阻塞！）
if err := container.Run(process); err != nil { // 注意：此处用 Run() 而非 Start()
return -1, fmt.Errorf("run process: %w", err)
}
// 6. 异步读取输出
go func() {
scanner := bufio.NewScanner(stdoutPipeR)
for scanner.Scan() {
onData(scanner.Bytes())
}
if err := scanner.Err(); err != nil {
onErr(err)
}
stdoutPipeW.Close() // 关闭写端，使读端 EOF
}()
// 7. 转发信号并等待退出
return sigHandler.forward(process)
}? 关键修正点：
- 使用 container.Run()（同步等待进程结束）替代 Start() + forward() 组合，避免信号 handler 状态错乱；
- Run() 内部会自动调用 wait4()，确保进程生命周期受控；
- 所有 defer 均置于函数起始处，防止资源泄漏。
⚠️ 必须规避的陷阱
- *❌ 复用主进程的 `os.File句柄**（如os.Stdin`）→ 导致容器与宿主机 stdin 争用；
- ❌ 在 Exec 中调用 container.Destroy() → 销毁整个容器，而非仅当前进程；
- ❌ 忽略 process.Init 字段 → 对于需要 init 进程语义的场景（如 PID 1 行为），需显式设置 process.Init = false；
- ❌ 未校验容器状态 → container.Status() 应为 Running，否则 Run() 会失败。
✅ 验证方法
- 启动一个长期运行的容器（如 sleep infinity）；
- 循环调用 Exec(container, &specs.Process{Args: []string{"sh", "-c", "whoami; ps aux"}}) 10 次；
- 观察：
- ps aux | grep whoami 应显示多个独立进程（非子进程树）；
- top -p $(pgrep -f "whoami") 内存占用稳定无增长；
- cat /proc/<pid>/cgroup 中所有进程位于同一 cgroup 路径下。
? 提示：参考 Docker 官方实现（daemon/execdriver/native）可深入理解生产级 exec 的资源清理、OOM 处理与审计日志集成逻辑。
掌握上述模式后，你将能可靠构建支持多进程协作的轻量容器运行时——既符合 OCI 规范，又具备生产环境所需的稳定性与可观测性。
