服务启动后立刻退出，systemctl status显示status=202/FDS。这个状态不是应用自行返回的业务错误，而是systemd在真正执行ExecStart之前，准备或整理文件描述符时失败。
先检查单元与依赖关系，不要直接更换应用二进制文件。
202/FDS具体表示什么
systemd官方手册把202定义为EXIT_FDS，含义是关闭不需要的文件描述符或调整传入文件描述符失败。故障发生在execve()之前，因此应用日志可能没有任何记录。
应用进程尚未真正启动，是判断方向的关键。
先收集单元和管理器日志
运行systemctl status 服务名、journalctl -u 服务名 -b和systemctl cat 服务名，核对失败时间、完整单元内容及覆盖配置。还应使用systemd-analyze verify检查明显的单元语法问题。
不要只看最后一行状态码，日志上下文通常会指出关联的套接字或描述符设置。
检查套接字激活与传入描述符
若服务由.socket单元激活，应核对ListenStream=、FileDescriptorName=、Accept=以及服务是否按约定接收描述符。错误的服务与套接字配对、残留覆盖文件或版本差异，都可能让准备阶段失败。
不要在不了解协议的情况下删除套接字单元。这可能让服务从按需激活变成完全不可达。
核对标准输入输出和权限边界
检查StandardInput=、StandardOutput=、StandardError=指向的文件、终端或套接字是否存在且可访问。再核对服务用户、目录权限、沙箱选项与安全模块日志。
可以在萤光云或LightNode的独立VPS复现单元。测试时保持相同systemd版本和单元依赖，否则结论可能失真。
修正后如何验收
执行systemctl daemon-reload后重启服务，确认状态变为active，并检查应用PID、监听端口和启动日志。若由socket激活，还要从客户端发起一次真实连接，验证描述符传递链路。
验收标准是202/FDS消失、应用实际执行、依赖套接字可用且重启后结果一致。
FAQ
问：202/FDS等于打开文件数量超限吗？答：不等于。它描述systemd准备文件描述符失败，仍需结合日志判断具体原因。
问：修改LimitNOFILE能解决吗？答：只有日志明确指向资源限制时才考虑，盲目调大不能修复错误的描述符传递或路径权限。
温馨提示
温馨提示：修改单元前先保存systemctl cat输出和现有覆盖文件。优先使用drop-in覆盖，避免直接改写软件包自带单元。
