Linux ulimit 怎样检查当前 shell 的文件描述符上限

遇到 Too many open files 时，先不要急着改系统配置。当前 shell 里，Linux 通常用 Bash 的 ulimit -n 查看“最多能打开多少个文件描述符”；其中 -S 代表软上限，-H 代表硬上限。最直接的检查组合是：

# 读取当前 shell 对打开文件描述符设置的软上限
ulimit -Sn

# 读取当前 shell 对打开文件描述符设置的硬上限
ulimit -Hn

两条命令都没有参数时只读取当前 shell 的限制，不会替你修改配置。下面按“负载、约束、选择、落地”的顺序，把这个结果怎样读清楚。

先把文件描述符上限拆成软上限和硬上限

文件、管道、网络连接都会占用文件描述符。-n 指向的就是打开文件描述符数量，-Sn 与 -Hn 读取同一资源的两条边界。软上限是当前进程通常受到的有效限制，硬上限是普通用户能够把软上限提高到的上界。

因此，看到两个数字时不要只记住较大的那个。若软上限较小，应用先会在软上限处遇到资源不足；若想把软上限提高，目标值通常不能超过硬上限，普通用户也不能随意提高硬上限。这个关系比某一台机器上的具体数字更重要。

图1：结构说明图。左侧是当前 shell 的读取入口，右侧是同一个文件描述符资源的软、硬边界。

用三种视角检查当前 shell

日常排障可以按“单项读取、完整列表、进程视角”比较三份信息：

# 只看打开文件描述符的软上限，适合快速判断当前会话
ulimit -Sn

# 只看打开文件描述符的硬上限，适合判断还能提高到哪里
ulimit -Hn

# 查看当前 shell 支持的全部资源限制，便于确认资源名称和单位
ulimit -a

# 查看当前进程内核限制的汇总，便于和 shell 内建结果对照
cat /proc/self/limits

ulimit -a 适合建立全景，但不同 shell 的输出标签和单位可能不同；/proc/self/limits 反映的是执行这条命令的进程上下文。不要把一份完整列表里的“文件大小限制”误认为“文件描述符数量”：Bash 中前者常对应 -f，后者对应 -n。

为什么脚本里查到的值不一定等于服务值

ulimit 是 shell 内建命令。它改变或读取的是当前 shell 的执行环境，后续由它启动的子进程通常会继承当时的资源限制；如果脚本由另一个启动器拉起，或者服务由独立的服务管理器启动，就不能用自己的交互 shell 结果代替服务进程的结果。

排查服务时，把检查命令放进同一启动上下文更可靠：

# 在目标脚本的同一 shell 中读取软、硬上限，避免比较错进程
printf 'soft=%s hard=%s\n' "$(ulimit -Sn)" "$(ulimit -Hn)"

# 读取当前脚本进程看到的内核限制；/proc/self 指向当前进程
grep 'Max open files' /proc/self/limits

如果交互 shell、脚本和服务的结果不同，先画出启动边界，再检查服务实际拿到的限制。修改了某个终端窗口里的 ulimit，不会自动改写已经运行的服务，更不会影响另一个独立登录会话。

图2：边界说明图。应在目标服务自己的进程上下文中读取 /proc/self/limits，而不是借用无关终端的结果。

按排障目标选择检查方式

一份稳妥的落地清单是：先在报错现场读取 -Sn，再读取 -Hn；确认你查的是 -n 而不是 -f；最后把同样的检查放到实际脚本或服务启动上下文中。只有确认限制确实是瓶颈后，再根据启动器和权限边界调整配置。

常见问题

只执行 ulimit -n 看的是软上限吗？

在 Bash 中，默认报告的是指定资源的软限制，所以排查时最好显式写成 ulimit -Sn，这样不容易把读取语义和 shell 默认行为混在一起。

为什么把硬上限调高后，程序还是报打开文件过多？

硬上限只是可调整边界，程序当前实际受到的往往仍是软上限；另外，服务可能由独立启动器创建，和你修改的交互 shell 不是同一个进程上下文。应在目标服务进程附近重新读取限制。

总结

检查当前 shell 的文件描述符上限，核心就是 ulimit -Sn 与 ulimit -Hn：前者回答“当前有效上限是多少”，后者回答“普通用户最多能提高到哪里”。再用 ulimit -a 看全局资源、用 /proc/self/limits 对照实际进程，就能把命令结果、权限边界和服务启动环境区分开。