使用 exec.Command 调用 runc start -d 时，若误用 CombinedOutput() 会导致程序无限等待——因其等待容器进程及其所有子进程彻底关闭 stdout/stderr，而守护模式下的容器会持续持有这些文件描述符。
使用 `exec.command` 调用 `runc start -d` 时，若误用 `combinedoutput()` 会导致程序无限等待——因其等待容器进程及其所有子进程彻底关闭 stdout/stderr，而守护模式下的容器会持续持有这些文件描述符。
在 Go 中通过 os/exec 启动 runc 容器并测量启动耗时，关键在于理解 runc start -d 的语义与 Go 进程通信机制的匹配关系。
runc start -d redis 的 -d（detached）标志表示：容器主进程将以守护模式运行，runc 自身会立即退出，但容器进程（如 Redis）会在后台持续运行，并继承父进程的标准 I/O 文件描述符。而 Go 的 cmd.CombinedOutput() 内部会调用 cmd.Wait() 并读取全部输出，它必须等到 所有对 stdout/stderr 的写入端全部关闭 才返回——这包括容器内进程持有的副本。由于守护容器通常长期运行且不关闭 stderr/stdout，CombinedOutput() 将永久阻塞。
✅ 正确做法是：仅启动命令、不等待输出、手动记录启动时间：
command := exec.Command("runc", "start", "-d", "redis")
command.Dir = "/containers/redis"
start := time.Now()
err := command.Start() // 非阻塞启动，立即返回
if err != nil {
fmt.Printf("failed to start container: %v\n", err)
return
}
// 此时 runc 已退出，容器已运行；我们可立即计算“启动延迟”
duration := time.Since(start) / time.Millisecond
fmt.Printf("runc start latency: %d ms\n", duration)
// 可选：等待 runc 进程真正结束（通常极快），确保启动指令已落地
if err := command.Wait(); err != nil {
fmt.Printf("runc process error (non-fatal): %v\n", err)
}
⚠️ 注意事项：
- 不要使用 Run() 或 CombinedOutput()，它们隐式调用 Wait() 并尝试读取流，与 detached 容器语义冲突；
- Start() 仅启动命令并返回，runc 进程退出即代表容器已成功交由容器运行时管理；
- 若需确认容器是否真正进入 running 状态，应在 Start() 后调用 runc state redis 或轮询 runc list，而非依赖 I/O 关闭；
- 确保容器配置（config.json）中 terminal 设置为 false，避免分配伪终端导致额外 I/O 持有。
总结：Go 中操作 runc 的 detached 容器，应遵循「启动即完成」原则——Start() 是语义正确的入口，配合显式计时与可选的状态校验，才能获得准确、低开销的启动性能数据。
