Linux ulimit -n 调高后仍报 too many open files

Linux 中把终端里的 ulimit -n 调大，却仍然看到 too many open files，最常见的原因不是命令失效，而是命令改到的进程和真正报错的进程不是同一个。ulimit 改的是当前 shell 的 RLIMIT_NOFILE；服务若由 systemd、容器或另一个登录会话启动，就不会自动继承你后来在终端里设置的值。

先读取报错进程的 /proc/PID/limits，再决定改 shell、systemd unit 还是内核全局参数。单进程达到 nofile 通常对应 EMFILE，所有进程合计触碰系统上限才考虑 file-max 与 ENFILE。

先确认报错进程到底拿到了什么限制

不要只在自己的终端执行 ulimit -n。先找到报错服务的 PID，再从 procfs 读取它的限制。下面的命令只读当前状态，不会修改系统配置。

# 把 PID 替换为真正出现 too many open files 的服务进程
pid=12345

# 查看该进程实际收到的 soft/hard open files 限制
grep -i 'open files' "/proc/$pid/limits"

# 统计当前打开的文件描述符数量，用于和 soft limit 对照
find "/proc/$pid/fd" -maxdepth 1 -type l 2>/dev/null | wc -l

# 查看当前 shell 的值，只能代表这个 shell 及其后续子进程
ulimit -Sn
ulimit -Hn

如果 shell 显示 65536，而服务的 /proc/PID/limits 仍是 1024，问题已经定位到启动链，而不是“Linux 没有保存配置”。另外，soft limit 是内核实际执行的门槛，hard limit 是普通进程可把 soft limit 调到的上限；两者都要看。

为什么在终端调大，对 systemd 服务仍然不生效

资源限制是进程属性：子进程会继承父进程的限制，执行新程序也会保留它。已经启动的服务不会因为另一个终端执行了 ulimit 就被更新；通过 sudo、计划任务或容器切换启动入口，也可能得到不同的父进程配置。

对 systemd 管理的服务，应在 unit 层设置，而不是把希望寄托在交互式 shell 上：

# 为目标服务创建 drop-in，避免直接改发行版自带 unit 文件
sudo systemctl edit demo.service

# 在编辑器中写入以下内容：soft 和 hard 同时设为 65536
[Service]
LimitNOFILE=65536:65536

# 让 systemd 重新读取 unit，并重启服务以建立新的进程继承链
sudo systemctl daemon-reload
sudo systemctl restart demo.service

# 重启后先取新 PID，再确认服务实际拿到的限制
pid=$(systemctl show -p MainPID --value demo.service)
grep -i 'open files' "/proc/$pid/limits"

如果服务不是 systemd 启动，而是通过登录会话运行，才继续检查 /etc/security/limits.conf、对应的 limits.d 文件和 PAM 是否加载 pam_limits.so。这些配置影响新建的登录会话，不会改变已经存在的 shell 或 daemon。容器场景还要在宿主机、容器运行时和容器内分别检查，不能只看宿主机的终端值。

把单进程耗尽和系统总量耗尽分开

单进程达到 RLIMIT_NOFILE 时，打开文件的系统调用通常返回 EMFILE；如果机器上所有进程合计触碰内核的文件句柄总量，则更接近 ENFILE。后者不能靠只给一个服务加大 LimitNOFILE 解决。

# 查看系统当前已分配、未使用和最大文件句柄数量
cat /proc/sys/fs/file-nr

# 查看系统级 file handle 总上限；它不是某个进程的 ulimit
cat /proc/sys/fs/file-max

# 查看单进程可设置的 RLIMIT_NOFILE 上界
cat /proc/sys/fs/nr_open

只有在证据显示系统总量接近 file-max 时，才评估内核参数和全机进程的 fd 使用情况。不要为了消除一条错误日志盲目写入很大的数值；过高的限制会掩盖连接未关闭、文件未关闭、日志轮转异常或管道泄漏。

用一次重启后的复查结束排障

修复后至少记录三项结果：服务新 PID 的 soft/hard nofile、当前 fd 数量与错误码、启动方式对应的配置位置。若限制已经高于业务峰值但 fd 数仍持续增长，下一步应按类型统计 /proc/PID/fd 指向的 socket、普通文件和 pipe，回到应用生命周期排查，而不是继续提高上限。

相关问题

为什么重新登录后 ulimit 才变化？

因为 limits 配置通常由 PAM 在创建新登录会话时应用；旧 shell 和旧服务已经保存了自己的进程限制，重新登录或重启服务才会建立新的继承链。

把 hard limit 调高就一定能解决 too many open files 吗？

不一定。真正触发打开失败的是报错进程的 soft limit；同时还要排除系统级 file-max、nr_open 和应用本身持续泄漏描述符。

相关事实可参考 Linux man-pages 的 getrlimit(2)、systemd.exec(5) 与 Linux 内核的 /proc/sys/fs 文档。