在Linux系统运维中，我们经常需要为特定用户配置资源上限，例如限制开发账号的内存占用，或防止测试用户过度消耗CPU资源。许多运维人员误以为Cgroup（控制组）可以直接根据用户名来实施资源限制。然而实际情况是，Cgroup的底层运作机制并非如此直接。
Cgroup 本身并不识别「用户」，只识别「进程组」；若要限制特定用户的资源使用，必须将该用户启动的所有进程统一纳入某个 cgroup，再通过 systemd 或手动挂载配合进程迁移来实现。
先给出明确结论：Cgroup 本身并不直接识别「用户」，其操作对象是「进程组」。要想为特定用户设定资源限制，必须把该用户产生的所有进程集中归入某个 cgroup，然后通过 systemd 或手动挂载加进程迁移的方式完成绑定。绕过这层映射关系，所有配置都将失效。
为什么 cgroup 不能直接按用户名限制资源
cgroup 属于内核级机制，其管控对象是进程（pid）及其所属的控制组，而非 UID 或用户名。系统中并不存在 user.max_memory 或 uid.1001.cpu_quota 这类接口。即便你通过 useradd 创建了用户，内核也不会直接感知其「用户身份」，内核只关心该用户启动的进程被分配到了哪个 cgroup。
- 所有基于用户名的资源限制，其本质都是「在用户登录或启动服务时，自动将其进程加入预设的 cgroup」。
- systemd 是当前最可靠、默认启用的自动化实现路径；手动方式容易遗漏子进程或通过 fork 产生的新进程。
- 如果你使用的是 cgroup v2（RHEL 9 / Ubuntu 22.04+ 默认采用），
/sys/fs/cgroup/user.slice下已存在按 UID 组织的层级结构，但这只是 systemd 的规则约定，并非内核原生支持。
用 systemd 为用户会话设置内存/CPU 限制（推荐方案）
这是现代 Linux 发行版中最稳定、最易于维护的实践方式，依赖 logind 和 systemd --user 自动为用户创建 slice。
- 编辑
/etc/systemd/logind.conf，取消注释并修改参数：UserTasksMax=512（限制单个用户的最大进程数）RuntimeDirectoryMode=0755（确保运行时目录权限正确） - 为特定 UID 创建 slice 配置：
新建文件/etc/systemd/system/user-1001.slice.d/limits.conf，写入以下内容：[Slice] MemoryMax=2G CPUQuota=30%
- 重载配置并生效：
sudo systemctl daemon-reload && sudo systemctl kill --kill-who=all --signal=SIGTERM user-1001.slice（强制下次登录时生效） - 验证方法：执行
loginctl show-user 1001 | grep Memory，或查看/sys/fs/cgroup/user.slice/user-1001.slice/memory.max
手动将已有进程迁入 cgroup（调试或临时场景）
此方法适用于未使用 systemd 登录的环境，或需要立即干预某个失控进程的情况。注意：该操作仅对当前进程有效，新 fork 出的子进程不会自动继承。
- 确认 cgroup v2 已启用：
mount | grep cgroup应显示type cgroup2 - 创建用户专属 cgroup：
sudo mkdir -p /sys/fs/cgroup/user-john - 设置内存上限：
echo "2147483648" | sudo tee /sys/fs/cgroup/user-john/memory.max - 配置 CPU 配额（例如限制为 1 核）：
echo "100000" | sudo tee /sys/fs/cgroup/user-john/cpu.max - 将目标进程 PID 加入 cgroup：
echo 12345 | sudo tee /sys/fs/cgroup/user-john/cgroup.procs - ⚠️ 注意事项：如果进程已 fork 出多个子进程，
cgroup.procs只会移入线程组 leader；需要借助tasks文件逐个写入所有tid，或改用systemd-run --scope启动整个进程树
systemd-run --scope 启动受控命令（最简便的可控方式）
此方案适合脚本化操作、CI/CD 流程或运维临时任务，能够天然捕获整个进程树，无需手动迁移。
- 限制某条命令最多使用 512MB 内存和 0.5 核 CPU 资源：
systemd-run --scope -p MemoryMax=512M -p CPUQuota=50% --uid=1001 bash -c 'sleep 300' - 查看效果：执行
systemctl status run-rXXXXX.scope，或读取对应 cgroup 路径下的memory.current和cpu.stat - 注意：
--scope模式不会持久化，进程退出后即自动销毁；若需长期守护运行，请改用--unit=xxx.service
实际运维中最容易被忽视的是子进程继承问题——无论采用哪种方式，只要没有显式使用 systemd-run --scope 或完整的 slice 配置，通过 fork 产生的后台任务、shell 子命令、nohup 进程等很可能逃脱资源限制。这并不是配置写错了，而是 cgroup 的设计逻辑使然：它管控的是「谁启动了你」，而不是「你是谁」。
