syscall.ForkExec不能直接设cgroup或ulimit，因为它仅封装fork+execve系统调用，不处理资源管理；需手动在fork后、exec前写cgroup.procs，并通过SysProcAttr.Rlimits设置传统rlimit（如RLIMIT_CPU），且受父进程限制约束。
syscall.ForkExec 为什么不能直接设 cgroup 或 ulimit
因为 syscall.ForkExec 是 Linux 系统调用的裸封装，它只做三件事：fork 一个子进程、在子进程中 execve 替换镜像、返回 pid。它不介入进程调度、资源管理或运行时环境配置——这些必须由调用方在 fork 前/后手动完成。
常见错误是以为传个 syscall.SysProcAttr 就能限制内存或 CPU，但实际该结构体仅支持 Setpgid、Setctty、Cloneflags 等内核级属性，不包含 cgroup 路径或 rlimit 设置字段。
-
syscall.SysProcAttr.Rlimits只能设置传统 Unix rlimit（如RLIMIT_NOFILE），无法控制 cgroup v2 的 memory.max 或 cpu.weight - 想用 cgroup，必须在 fork 后、exec 前，由父进程把子进程 pid 写入对应 cgroup.procs 文件
- 写入 cgroup.procs 需要父进程有相应权限（通常需 root 或 cgroup namespace capability）
如何在 ForkExec 后立即绑定 cgroup v2
关键时机是在 syscall.ForkExec 返回但子进程尚未 exec 之前——此时子进程处于“暂停”状态（因 exec 会覆盖地址空间，但尚未发生），父进程可安全将其加入 cgroup。
实操分三步：创建 cgroup 目录、写入资源限制值、将子进程 pid 写入 cgroup.procs。注意路径必须绝对且已挂载 cgroup v2（通常是 /sys/fs/cgroup）。
立即学习“go语言免费学习笔记（深入）”；
- 确保 cgroup v2 已启用：
mount | grep cgroup2，若无输出需在 kernel cmdline 加systemd.unified_cgroup_hierarchy=1 - 创建临时 cgroup：
mkdir -p /sys/fs/cgroup/myapp-$$（$$是 bash pid，Go 中可用os.Getpid()拼接） - 设内存上限：
echo 100000000 > /sys/fs/cgroup/myapp-$$/memory.max（单位字节） - 写入子进程 pid：
echo <pid> > /sys/fs/cgroup/myapp-$$/cgroup.procs</pid>，此操作必须在exec前完成，否则子进程启动后可能已脱离控制
syscall.ForkExec 中 Rlimit 设置的生效边界
syscall.SysProcAttr.Rlimits 数组确实能设 RLIMIT_AS、RLIMIT_CPU 等，但它只影响 exec 后的子进程初始 rlimit，且受父进程 limit 和系统策略双重约束。
例如：父进程 soft limit 是 1024 文件描述符，即使你设 Rlimit{Type: syscall.RLIMIT_NOFILE, Cur: 64, Max: 64}，子进程仍可能拿到 1024——因为内核只允许降低 soft limit，且 Cur 不能高于当前 soft 值。
- 生效前提：父进程 rlimit 允许下调（
getrlimit(RLIMIT_NOFILE, &rlim)查看当前值） -
Max字段必须 ≥Cur，否则ForkExec直接返回EINVAL -
RLIMIT_CORE设为 0 可禁用 core dump，但某些内核版本对 setuid 进程会忽略该设置 - 对 Go runtime 自身的 goroutine 调度无影响，它只约束 OS 级资源
替代方案：什么时候该放弃 ForkExec 改用 exec.Command
如果你需要自动继承环境变量、重定向 stdin/stdout、超时控制、信号转发或组合管道，exec.Command 是更安全的选择——它内部也用 ForkExec，但封装了大量易错逻辑。
真正需要裸调 syscall.ForkExec 的场景极少，典型包括：实现容器 runtime 的 init 进程、调试 ptrace 工具、或在极简嵌入式环境中绕过 libc 依赖。
- 用
exec.Command也能设 rlimit：cmd.SysProcAttr = &syscall.SysProcAttr{Rlimits: [...]}，行为与裸调一致 - 若需 cgroup，
exec.Command启动后同样要手动写cgroup.procs，无本质区别 - 裸调最大的坑是忘记设置
Setpgid: true，导致子进程和父进程共享信号组，Ctrl+C 会同时杀死两者
cgroup 路径写错、权限不足、或写入 cgroup.procs 的时机晚于 exec，这三类问题占实际调试时间的 80% 以上。
