服务启动后立刻显示 status=211/IOPRIO，表示systemd在执行程序之前，设置I/O调度类别或优先级失败。应用进程此时可能尚未真正运行。
排查重点是单元中的 IOSchedulingClass=、IOSchedulingPriority=、运行权限和环境限制。不要把211当成应用自己返回的业务退出码。
先确认结果码和失败阶段
读取完整状态、当前启动日志和执行结果：
systemctl status example.service --no-pager -l
journalctl -u example.service -b --no-pager -n 120
systemctl show example.service -p Result -p ExecMainCode -p ExecMainStatussystemd将211定义为 EXIT_IOPRIO，含义是建立I/O调度优先级失败。应用日志为空并不奇怪，因为错误发生在 ExecStart 之前。
查看最终生效的IO调度配置
主单元和drop-in都可能写入调度参数，先读取合并结果：
systemctl cat example.service
systemctl show example.service \
-p IOSchedulingClass -p IOSchedulingPriority同时查看文件来源：
systemctl show example.service -p FragmentPath -p DropInPaths只编辑最先找到的service文件可能无效，后加载的drop-in仍会覆盖它。
核对类别与优先级取值
IOSchedulingClass=可设置 realtime、best-effort 或 idle。对于 realtime 与 best-effort，IOSchedulingPriority=使用0到7，0优先级最高，7最低。
配置拼写错误、超出范围或把不适用的参数组合在一起，都应先修正。没有明确性能目标时，不要照搬高优先级模板；错误的实时I/O策略可能挤压同机其他服务的磁盘访问。
检查权限、容器和内核边界
实时I/O类别可能受到能力、服务沙箱、容器运行时或宿主机策略限制。先查看运行身份与安全属性：
systemctl show example.service \
-p User -p Group -p CapabilityBoundingSet \
-p NoNewPrivileges -p PrivateDevices容器内的systemd还受宿主机控制，来宾配置不一定能覆盖外层限制。不要为了通过启动而直接关闭全部安全选项或给服务完整特权。
用ionice验证系统支持情况
可以在同一主机上用低风险命令检查类别和优先级是否可设置：
ionice -c 2 -n 4 true
echo $?
ionice -p $$这只能验证当前会话的基础能力，不能代替服务身份测试。若单元使用专用用户、命名空间或严格能力边界，仍需在相同条件下验证。
用drop-in做最小调整
确认业务并不需要特殊I/O优先级后，使用：
sudo systemctl edit example.service在自有drop-in中改为经过评审的类别与优先级，例如：
[Service]
IOSchedulingClass=best-effort
IOSchedulingPriority=4随后执行 systemctl daemon-reload 并重启服务。需要在隔离服务器复现单元配置时，可以使用 萤光云 或 LightNode 建立测试环境。生产数据库、队列和日志服务不要在没有I/O基线的情况下调整为realtime。
修复后怎样验收
重新启动并读取实际结果：
sudo systemctl restart example.service
systemctl is-active example.service
systemctl show example.service \
-p Result -p ExecMainStatus -p IOSchedulingClass -p IOSchedulingPriority验收标准是211/IOPRIO不再出现，应用进程成功执行，实际调度参数符合预期，并且同机关键服务的I/O延迟没有异常上升。
FAQ
删掉IOSchedulingPriority就一定能启动吗？ 只有错误确实来自该项时才有效，还需检查类别、权限、容器限制和其他drop-in覆盖。
best-effort的0是不是最安全？ 0代表更高优先级，并非更安全。没有性能数据时使用中间值更容易控制对其他服务的影响。
温馨提示
修改前保存 systemctl cat 和关键属性输出，便于回滚。先恢复服务可启动，再根据监控数据决定是否需要特殊I/O调度。
