科技 · 实用指南
systemd 报 status=218/CAPABILITIES？先证明管理器、内核与能力集
程序可能根本没有运行。保存第一条 journal 错误，读取生效 unit，区分系统、用户和容器边界，只修改证据证明无效的能力转换。
218/CAPABILITIES 表示 systemd 在程序执行前无法丢弃能力或应用 ambient capabilities。应用日志可能尚未产生。
不要先删除全部加固项、改用 root 或授予 CAP_SYS_ADMIN。先确定失败步骤、管理器、命名空间、内核和能力集。
保存第一条能力阶段证据
保存首次 status 与 journal，区分 drop、ambient 或 namespace 失败，并记录 systemctl 还是 --user。
先停掉快速重启循环，再保存 FragmentPath、DropInPaths 与管理器，避免把继承的 drop-in 当成主文件。
读取生效 unit 的全部能力控制
从合并 unit 读取 BoundingSet、Ambient、NoNewPrivileges、SecureBits、PrivateUsers 等，并记录 User= 与程序。
比较 systemd 必须构建的能力集；ambient 依赖 permitted 和 inheritable，bounding set 也可能截断请求。
定位管理器、内核与容器边界
区分 PID 1、用户管理器、容器或旧内核/旧 systemd，只在相同边界复现。
用户管理器要核非特权用户命名空间；容器要核外层策略和 bounding set。
不扩大权限，只修一个已证明矛盾
只修一个证据明确的错配：管理器范围、继承指令、集合成员、已证实兼容性或容器策略。
不要用全部能力或 CAP_SYS_ADMIN 代替窄需求；不再需要的能力应删除并记录理由。
启动一次，核对能力集与真实工作
unit 改动后才在同一管理器 reload，必要时清速率限制，再启动一次并看新 journal。
核对 PID 的四个能力字段，再完成一次真实绑定、tun/tap 或其他所需操作，确认没有额外权限。
