报错是这么冒出来的。在 shell 里把文件句柄上限调到六万多，重启服务后进程实际限制还是幺零二四，业务高峰期照样报句柄不足。
真正麻烦的地方在于，几个原因的现象几乎一样。shell 里的设置只对当前会话有效。少数情况下是服务由初始化进程拉起，不继承登录会话的限制。
还有一种情况，PAM 的限制配置只对交互式登录生效。
动手时先确认进程实际限制
grep 'open files' /proc/$(pidof nginx)/limits直接编辑服务的单元文件
systemctl edit nginx --full接着在单元里设置上限
grep -n LimitNOFILE /etc/systemd/system/nginx.service等前面都确认过，再重载并核对结果
systemctl daemon-reload && systemctl restart nginx报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
白天有业务在跑，能验证的部分都压到了晚上做。
怎么算真的好了，看的是同一批现象。进程限制文件里显示六万多，业务高峰不再出现句柄耗尽报错。
系统级总上限也要同步放开，否则单进程设得再大，最终仍会被内核总量卡住。报错文案容易误导，真正的原因往往在相邻那一层的日志里。