服务启动后立即退出，systemctl status显示status=206/OOM_ADJUST。这个状态发生在systemd执行应用程序之前，表示服务进程的OOM评分调整没有成功。
它与应用运行后被OOM killer终止是两种不同故障。
206/OOM_ADJUST具体表示什么
systemd官方将退出码206定义为EXIT_OOM_ADJUST，对应OOMScoreAdjust=设置失败。该值范围是-1000到1000；数值越低，进程越不容易在内存压力下被内核选择，-1000表示禁止通过常规OOM选择终止该进程。
206说明启动准备失败，应用自己的日志可能完全没有产生。
先区分配置失败与真实OOM
查看systemctl status 服务名、journalctl -u 服务名 -b和systemctl cat 服务名。若是206，重点找OOMScoreAdjust=及其drop-in；若服务已经运行一段时间后消失，则还要查看内核日志、Result=oom-kill和内存监控。
不要因为看到OOM字样就直接增加内存。无效取值或权限不足同样会在启动前触发206。
核对取值和权限边界
使用systemctl show 服务名 -p OOMScoreAdjust读取生效值，并用systemd-analyze verify检查单元。系统管理器通常能设置合法范围；用户服务管理器可能无权把oom_score_adj降低到更受保护的负值，容器也可能被能力集限制。
极端的-1000会保护进程但可能让系统在内存耗尽时只能终止其他关键服务。应依据业务优先级选择可解释的值。
使用drop-in最小修正
执行systemctl edit 服务名，在[Service]中修正或移除错误的OOMScoreAdjust=，然后运行systemctl daemon-reload并重启服务。若配置来自软件包或编排工具，应在源配置中同步修改。
OOMPolicy=控制服务进程被OOM终止后systemd怎样处理单元，不替代OOMScoreAdjust=。不要把两个选项当成同一功能。
如何确认修复完成
服务启动后读取/proc/PID/oom_score_adj并与单元期望值比较，再检查状态、日志与重启结果。可在萤光云或LightNode的测试VPS复现。验收标准是206消失、应用实际执行、OOM分数正确且不会通过保护一个进程放大整机风险。
FAQ
问：把OOMScoreAdjust设为-1000能防止服务崩溃吗？答：只能降低被内核OOM机制选择的可能，不能修复应用自身崩溃、内存泄漏或cgroup限制。
问：OOMPolicy=stop能解决206吗？答：不能。206发生在执行程序前，应先修复OOMScoreAdjust的值或权限。
温馨提示
温馨提示：调整OOM优先级前先盘点同机数据库、SSH和监控等关键服务。保护策略应与MemoryMax、交换空间和容量告警一起设计。
