Linux Cgroup实战：限制用户资源占用与容器底层原理

在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 加入：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 的设计使然：它管理的是「谁启动了你」，而非「你是谁」。