Linux LimitNOFILE 改了仍是 1024：unit 覆盖与新 PID 校验

给 Linux 服务的 unit 配置里加了 LimitNOFILE=131072 之后，重启服务跑起来一看，进程的打开文件资源上限还是默认的1024，不用急着反复把数值往高调。出现这种情况最常见的几个原因，无非是配置写到了根本不会被加载的unit层级、服务管理器还没重新读取磁盘上刚改的新文件，或者服务当前跑的还是带着旧限制的老PID。核对这类配置的时候，要把管理器解析出来的unit静态配置，和新进程实际继承到的运行态限制拆成两步，分开单独校验。

你不需要花大量时间去排查内核全局参数，先确认配置落对了正确的unit文件、重载服务管理器配置、重启服务后确认拿到了全新的服务PID，LimitNOFILE不生效的问题通常就能定位。

先确认服务管理器到底读取了哪个 unit

一个服务的配置可能来自发行版自带的原生unit、管理员手动添加的drop-in覆盖，甚至是模板实例的专属配置。随便点开一个你以为的文件改，很容易把改动写到根本不会被目标服务加载的位置。先把所有生效的配置来源完整打印出来：

sudo systemctl cat api-worker.service
sudo systemctl show api-worker.service -p FragmentPath -p DropInPaths
sudo systemctl show api-worker.service -p LimitNOFILE

FragmentPath 用来确认主unit的加载路径，DropInPaths 用来确认所有覆盖配置的存储路径，最后一条输出直接返回服务管理器当前解析出的最终限制值。如果服务实际名称是 api-worker@blue.service，不要把模板 api-worker@.service 和实例配置混在一起核对。

用 drop-in 写入 [Service] 段

发行版自带的unit文件很可能在系统包升级的时候被覆盖重置，直接编辑系统unit存储路径下的原生文件，既不利于后续审计，出问题也没法快速回滚。更稳妥的做法是创建独立的覆盖配置文件：

sudo systemctl edit api-worker.service

在编辑器中写入对应配置内容：

[Service]
LimitNOFILE=131072

这个参数属于 [Service] 段，放到 [Unit] 或 [Install] 都不会得到预期的运行效果。写完之后要检查合并后的完整unit配置，不能只看编辑器里刚写的几行内容就直接跳过校验：

sudo systemctl cat api-worker.service
sudo systemd-analyze verify api-worker.service

让配置从磁盘进入运行态

保存完drop-in文件后，正在运行的服务管理器和存量服务进程不会自动同步新的限制参数。先让服务管理器重新扫描所有unit文件，再在提前约定好的维护窗口内重启目标服务：

sudo systemctl daemon-reload
sudo systemctl restart api-worker.service
systemctl is-active api-worker.service

daemon-reload 解决“管理器还在使用旧内存缓存的unit配置”的问题，restart 解决“旧进程仍保留继承自启动时的旧限制”的问题。只执行其中任意一步，都有可能出现静态配置看起来完全正确，但运行态结果完全不变的情况。生产环境的服务调整前，要先确认健康检查逻辑、连接排空机制和预留足够的回滚窗口。

用新 MainPID 做最终验收

验收的时候不要直接拿当前终端的 ulimit -n 输出代替服务进程的实际限制。交互式Shell和服务管理器是两条完全独立的启动链路，会读取完全不同的配置规则。按下面的顺序拿到服务的主PID再做校验：

pid="$(systemctl show -p MainPID --value api-worker.service)"
echo "pid=$pid"
grep -E 'Max open files|open files' "/proc/$pid/limits"
sudo systemctl show api-worker.service -p LimitNOFILE

如果 MainPID=0，先检查 systemctl status 和服务运行日志；如果管理器解析出来的配置值已经更新，但新启动的PID对应的运行态限制还是旧值，再回头检查当前修改的drop-in是不是对应正确的unit实例。最终的变更记录里要包含unit名称、配置文件存储路径、解析出的限制值、验收用的PID和验收时间。

回滚与变更边界

调大这个资源上限只是放宽进程可以申请的额度，并不等于应用本身已经适配了更高的并发容量。连接池、线程池、内存阈值和监控告警规则仍要按服务自身的容量模型同步调整。需要回滚的时候直接删除或者恢复之前的drop-in文件，再执行完全相同的重载、重启和新PID验收流程即可：

sudo systemctl revert api-worker.service
sudo systemctl daemon-reload
sudo systemctl restart api-worker.service

如果这类变更来自版本发布流程，建议把drop-in配置和对应的变更单一起归档留存，避免下一次系统包升级后只留下一个孤立的数值，找不到当时调整的依据。

常见问题

改完 LimitNOFILE 后必须重启整台机器吗？

不需要。通常重新加载unit配置并重启目标服务即可，能不能做到业务无损切换取决于服务本身的连接排空和发布机制。

服务管理器 show 与服务进程的limits结果不一致怎么办？

先确认读取的是同一个unit实例，再确认当前服务的MainPID是不是已经发生了变化。服务管理器里的解析值和旧进程继承的运行值本来就可能处在不同状态，属于正常现象。

可以直接改发行版自带的unit文件吗？

不建议。用 systemctl edit 创建drop-in覆盖配置能清晰保留变更边界，也不容易被后续系统升级覆盖。

LimitNOFILE 设置得越大越好吗？

不是。它只是允许进程申请的上限值，应该结合服务的连接模型、线程数规划、内存占用和告警规则综合确定，变更完成后仍要持续观察相关业务指标。

把验收证据留在变更记录里

这类配置调整的可靠闭环流程是：确认unit加载来源，验证drop-in配置内容，执行 daemon-reload，重启服务，读取新PID对应的 limits，最后提前确认回滚方式。只要把管理器的静态解析值和运行态PID的实际继承值分开核对记录，LimitNOFILE “改了却不生效”的问题通常都能快速定位到具体出错的环节。