科技 · 实用指南
systemd status=219/CGROUP？改委派前先读清失败的 cgroup 操作
这个代码只标出设置阶段，不代表单一修法。保留日志动词、errno 与路径，映射管理器和层级，只修一个所有权边界，再证明一次干净启动。
这个代码只标出设置阶段，不代表单一修法。保留日志动词、errno 与路径，映射管理器和层级，只修一个所有权边界，再证明一次干净启动。
状态 219 表示 systemd 在设置服务控制组时失败，并不对应唯一原因。
1. 冻结第一条 CGROUP 日志
在 reset-failed、重启、重开机或改权限前保存 systemctl status 与首次失败周围的完整 journal。保留原动词：create、attach、enable、migrate 与 change ownership 是不同分支。
记录 errno 与完整 cgroup 路径。最终的 status=219/CGROUP 只说明设置阶段；之前的管理器日志才给出修复必须解释的对象与操作。
2. 识别负责的管理器
判断失败单元属于 PID 1、systemctl --user、容器 init 还是嵌套管理器。记录管理器版本、内核、虚拟化，以及同一 UID 或单元在边界外是否正常。
不要假定服务进程造成错误，它可能尚未执行。把单元 ControlGroup 属性与尝试创建或附加它的管理器对应起来。
3. 只读映射实时层级
只读检查 /sys/fs/cgroup 的 mountinfo 或 findmnt、cgroup 类型、相关控制器、systemctl show 属性与 systemd-cgls。列出受影响单元或父层下的存活进程，不移动也不终止。
建立所有权账本：主机管理器拥有委派单元以上的树，委派方只拥有其子树。在 cgroup v2 中，内部节点与控制器规则会让残留进程或手动子树改动阻塞下一次启动。
4. 分类修复分支
按证据分支：ENOENT 可能是层级或容器挂载缺失；EROFS 是只读边界；EACCES/EPERM 是所有权或委派不匹配；EBUSY 是存活进程或不兼容子树状态。编辑前核对发行版与容器约束。
只改一个边界。避免递归 chmod/chown、全局 Delegate=yes、关闭资源控制或删除 cgroup 目录。若单元拥有子组，修改控制器状态或重启策略前要停止并核清所有进程。
5. 证明一次受控启动
在观察下只启动一次，然后重读 status、journal、ControlGroup 与 systemd-cgls。验证预期路径和所有权、预期控制器、服务健康检查以及没有新 219 日志。
若修复依赖重启、容器宿主调整或厂商更新，要明确说明并保留前后证据。除非解释原失败操作，否则不要把一次偶然成功重试称为永久修复。
