Linux ulimit -n 提高后服务仍然打开文件数不足怎么办

在终端里执行 ulimit -n 65536，只会改变当前 shell 以及它后来启动的子进程；已经由 systemd 拉起的服务不会因此自动更新。所以看到 shell 的值已经变大、服务仍报“Too many open files”，通常不是 Linux 没有生效，而是检查错了进程边界。正确做法是先读服务 PID 的实际限制，再在 unit 中设置 LimitNOFILE=，重启后从 /proc//limits 复查。

先确认服务进程的 soft/hard nofile，再改 systemd 配置；只改交互式 shell 的 ulimit，无法修复已运行服务。

先分清 ulimit、systemd 与服务进程的限制边界

文件描述符上限属于进程资源限制。当前 shell 中运行 ulimit -Sn 和 ulimit -Hn，看到的是这个 shell 的 soft limit 与 hard limit；它们会被子进程继承，但不会反向修改别的进程。limits.conf 由 PAM 在登录会话建立时应用，同样是按登录会话生效，不是永久修改所有正在运行的服务。

systemd 服务没有必要经过你的交互式 shell。systemd 官方文档把 LimitNOFILE= 定义为服务进程的 soft/hard 资源限制，单个值会同时设置两者，冒号格式则可以分别设置。服务实际拿到的值才是排查入口：

# 先看当前 shell，避免把 shell 的结论当成服务结论
ulimit -Sn
ulimit -Hn

# 找到 systemd 记录的主进程 PID，再检查该进程的实际限制
pid=$(systemctl show -p MainPID --value myapp.service)
grep 'Max open files' "/proc/$pid/limits"

# util-linux 的 prlimit 可以同时显示指定 PID 的 nofile 限制
prlimit --pid "$pid" --nofile

用 LimitNOFILE 给目标服务设置可继承上限

systemd 服务的官方配置说明位于 https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html。对单个服务，建议使用 drop-in，而不是直接修改发行版提供的 unit 文件：

# 为 myapp.service 创建可追踪的本地覆盖配置
sudo systemctl edit myapp.service

# 在编辑器中写入以下内容；65536 只是示例，应按连接数和程序兼容性评估
[Service]
LimitNOFILE=65536:65536

如果只写 LimitNOFILE=65536，systemd 会把 soft 和 hard 都设为 65536；写成 65536:262144 则表示 soft 为 65536、hard 为 262144。soft 值不能超过 hard 值。对由容器、supervisor 或用户态 systemd 管理的服务，还要确认上一级进程允许的 hard limit，否则下层不能凭空突破它。

systemd 的 DefaultLimitNOFILE= 只是服务默认值，单个 unit 的 LimitNOFILE= 可以覆盖它；它也不会修改 systemd PID 1 自身的限制。配置完成后执行：

# 让 systemd 重新读取 drop-in，再重启生成新的服务进程
sudo systemctl daemon-reload
sudo systemctl restart myapp.service

# 先确认 unit 展开的配置，再读取新主进程的实际值
systemctl show myapp.service -p LimitNOFILE -p MainPID
pid=$(systemctl show -p MainPID --value myapp.service)
grep 'Max open files' "/proc/$pid/limits"

数值变大后仍报错，继续看三个边界

第一，确认报错进程不是旧 PID。服务重启后 PID 通常会变化，应用若自行 fork 或由 supervisor 再次拉起子进程，也要检查真正打开 socket、日志或文件的那个 PID。第二，检查 hard limit：soft 可以在 hard 范围内调整，但不能超过 hard；容器运行时或上级服务已经给出的上限可能更低。

第三，不要只追求更大的数值。systemd 文档提醒，Linux 上 select() 无法处理编号高于 1023 的文件描述符；仍依赖 select 的旧程序把 soft limit 直接抬过 1024，可能暴露新的兼容性问题。能使用 epoll、poll 或其他现代 I/O 模型的程序，再结合连接规模设置上限会更稳妥。打开文件数上涨也可能是连接、日志或文件没有关闭，调高上限不能替代泄漏排查。

上线检查可以固定为：查看 unit 配置、记录新 PID、读取 /proc 的 soft/hard 值、观察应用打开文件数曲线，并确认重启后的连接和日志恢复正常。只有这几项同时成立，才算完成一次有效调整。

常见问题

改了 /etc/security/limits.conf 为什么 systemd 服务还是不变？

该文件由 PAM 作用于登录会话，服务可能根本不是从该会话启动。对 systemd 服务直接使用 unit 的 LimitNOFILE=，并重启服务。

LimitNOFILE 应该写一个值还是两个值？

一个值同时设置 soft 和 hard；需要让 soft 较低、保留提升空间时使用 soft:hard，例如 65536:262144。

看到 Max open files 很大，为什么应用仍然报错？

可能检查的是错误 PID，也可能是应用自身连接池、文件泄漏或容器上游限制。先用 prlimit --pid PID --nofile 确认进程，再定位具体打开文件来源。