Linux cgroup v2 cgroup.events 怎样监控层级冻结状态

在生产环境里，清理一个服务的 cgroup 或等待冻结完成时，最容易混淆的是“里面没有进程”和“已经冻结”这两个状态。Linux cgroup v2 的 cgroup.events 提供了两个只读字段：populated 表示当前 cgroup 及其子孙层级是否还有活进程，frozen 表示冻结状态是否已经完成。它们可以一起用于清理判断，但不能互相替代。

官方文档：https://docs.kernel.org/admin-guide/cgroup-v2.html

实际监控时先读 populated 判断层级是否为空，再读 frozen 判断冻结是否完成；populated=0 只能说明没有活进程，不能证明 cgroup 已经冻结。

先分清 cgroup.events 的两个字段

cgroup.events 是非根 cgroup 中的只读平面键值文件。它的值属于当前层级的状态快照，但两个字段的观察范围不同：

• populated：当前 cgroup 或它的任意子孙 cgroup 中存在活进程时为 1，整个层级没有活进程时为 0。
• frozen：当前 cgroup 处于冻结状态时为 1，否则为 0。它反映的是冻结状态，而不是进程数量。

这一区分很重要：一个 cgroup 可以没有进程但没有执行过冻结，也可以在冻结期间仍然保留属于它或子孙层级的进程。监控代码应该按字段语义命名，避免把一个布尔值包装成含义更宽的 is_ready。

用只读文件读取层级状态

先把目标限定为非根 cgroup，再读取文件。下面的示例只做状态读取，不写入 cgroup.freeze，适合作为发布后的低风险复查脚本。路径应替换为实际服务对应的 cgroup 目录。

#!/usr/bin/env bash
# 读取目标 cgroup 的只读状态，不改变 cgroup 配置。
set -eu

# 生产环境通过参数传入目录，默认值只作为示例路径。
CGROUP_DIR="${1:-/sys/fs/cgroup/my-service}"
EVENTS_FILE="$CGROUP_DIR/cgroup.events"

# 先确认目标是非根 cgroup 且接口文件可读。
if [ ! -r "$EVENTS_FILE" ]; then
  echo "无法读取 $EVENTS_FILE" >&2
  exit 1
fi

# 只提取内核定义的两个字段，忽略未来可能新增的键。
populated=""
frozen=""
while IFS=' ' read -r key value _; do
  case "$key" in
    populated) populated="$value" ;;
    frozen) frozen="$value" ;;
  esac
done 

脚本只依赖键名，不依赖字段顺序。内核文档明确提醒，键值文件应按键查找而不是按固定位置解析；这样即使接口将来增加字段，也不会把新字段误读成旧含义。

把空层级和冻结完成拆成两个判断

如果目标是回收一个已经退出的服务，通常先关心 populated=0：它说明当前 cgroup 及后代没有活进程，可以进入清理候选状态。如果目标是等待冻结动作完成，则应等待 frozen=1。两者同时出现时，说明层级既没有活进程，又处于冻结状态；但这不是所有场景都要求的组合。

下面是一个不依赖额外监控代理的轮询思路。它适合低频维护窗口；高频场景应把文件变更通知交给已有的事件采集器，并在收到事件后重新读取完整文件。

#!/usr/bin/env bash
# 轮询直到观察到指定状态；每次都重新读取完整键值文件。
set -eu

CGROUP_DIR="${1:-/sys/fs/cgroup/my-service}"
EVENTS_FILE="$CGROUP_DIR/cgroup.events"
INTERVAL_SECONDS="${INTERVAL_SECONDS:-1}"

for _ in 1 2 3 4 5 6 7 8 9 10; do
  # 默认按未满足处理，避免缺字段时误报成功。
  populated="unknown"
  frozen="unknown"
  while IFS=' ' read -r key value _; do
    case "$key" in
      populated) populated="$value" ;;
      frozen) frozen="$value" ;;
    esac
  done &2
exit 2

通知、祖先影响和复查边界

内核文档说明，cgroup.events 的值发生变化时通常会生成文件修改事件；populated 的更新还会沿层级递归影响相关 cgroup。生产实现可以监听文件变化，但通知只说明“状态可能变化”，不应直接把通知名称当成最终状态，正确做法是收到通知后重新读取 cgroup.events。

冻结状态还要考虑祖先 cgroup：如果祖先被冻结，后代也会受到冻结影响。因此复查时至少保留目标路径、读取时间、两个字段值和祖先路径信息。不要只记录一个“冻结成功”的日志字符串，否则出现层级嵌套时很难解释结果来自哪一层。

发布前后的四项检查

1. 确认监控对象是非根 cgroup，并且读取权限覆盖 cgroup.events。
2. 确认解析逻辑按键名读取，不假设字段顺序，也不把缺失字段当作 0。
3. 确认清理条件与冻结条件分开：清理通常看 populated=0，冻结完成看 frozen=1。
4. 确认收到文件变更通知后会重新读取文件，并为祖先冻结和状态延迟留出复查窗口。

常见问题

populated=0 能说明服务已经安全退出吗？

它只说明该 cgroup 及其子孙层级当前没有活进程。是否可以删除目录、清理外部资源，还要结合服务管理器、挂载点和业务侧退出确认。

为什么 frozen=1 但 populated 仍然是 1？

冻结会停止进程运行，不会把进程从 cgroup 中移除。因此冻结层级仍可能保留进程，两个字段同时为 1 是合理状态。

监听到文件变化后可以直接执行清理吗？

不建议。通知是重新读取的触发信号，不是清理授权。应再次读取 cgroup.events，并结合权限、祖先层级和服务管理器状态做最终判断。

记住一句话：populated 回答“层级里还有没有活进程”，frozen 回答“冻结是否已经完成”。把这两个问题拆开，cgroup v2 的监控日志和清理策略就不容易互相误导。