服务一启动就退出，systemctl status显示status=205/LIMITS。这不是应用主动返回的错误，而是systemd在执行ExecStart之前设置进程资源限制时失败。
应用此时通常还没有真正运行，先检查单元限制与服务管理器权限。
205/LIMITS具体说明什么
systemd官方把退出码205定义为EXIT_LIMITS，含义是调整资源限制失败。相关指令包括LimitNOFILE=、LimitNPROC=、LimitMEMLOCK=、LimitCORE=等。错误可能来自无效数值、软硬限制顺序错误，或管理器无权提高现有上限。
205指向启动准备阶段，不等于应用已经耗尽某项资源。
先保存日志和实际生效配置
依次查看systemctl status 服务名、journalctl -u 服务名 -b与systemctl cat 服务名，确认失败时间、完整单元和所有drop-in。再运行systemctl show 服务名 -p LimitNOFILE -p LimitNPROC -p LimitMEMLOCK读取管理器准备应用的值。
修改前可用systemd-analyze verify /etc/systemd/system/服务名.service检查单元及依赖。不要只编辑软件包自带文件，因为真正覆盖它的可能是另一个drop-in。
核对Limit指令与版本边界
单个值会同时设置软、硬限制；需要分别设置时可使用soft:hard格式，例如LimitNOFILE=65536:65536。软限制不能高于硬限制。官方还说明LimitRSS=在Linux上没有效果，服务整体的内存和任务数通常更适合用MemoryMax=与TasksMax=控制。
不要盲目把所有限制改成infinity。高文件描述符上限不能修复程序泄漏，旧程序使用select()时也可能无法处理1023以上的描述符。
用drop-in进行最小修正
执行systemctl edit 服务名创建覆盖文件，只写入确认需要调整的[Service]与Limit项。系统服务通常可以由管理员提高限制；用户服务不能超过用户管理器启动时继承的硬上限，必要时应调整user@.service或登录会话的上游限制并重启用户管理器。
先确认应用真实需求，再把数值提高到可解释的范围。保存后执行systemctl daemon-reload，避免直接改写发行版维护的单元文件。
重启后的验收方法
重启服务后检查状态、PID和journalctl -u 服务名 -b，再从/proc/PID/limits读取运行进程的实际限制。可以在萤光云或LightNode的测试VPS复现相同单元。验收标准是205/LIMITS消失、应用确实运行、实际限制符合预期且重启后保持一致。
FAQ
问：205/LIMITS就是LimitNOFILE太小吗？答：不一定。任何资源限制设置失败都可能返回205，必须结合日志和实际生效配置判断。
问：修改limits.conf就一定有效吗？答：不一定。systemd系统服务通常不依赖交互登录会话的PAM限制，应在单元或管理器层确认配置来源。
温馨提示
温馨提示：调整资源限制前记录原值和业务峰值，并保留回滚用drop-in。对数据库、代理等高连接服务，限制提高后还要同步评估内存与内核容量。
