科技 · 實用指南
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 日誌。
若修復依賴重開機、容器宿主調整或廠商更新，要明確說明並保留前後證據。除非解釋原失敗操作，否則不要把一次偶然成功重試稱為永久修復。
