Linux 服务的文件句柄上限，为什么不能只看终端里的 ulimit？

在终端查到文件描述符上限很高，服务仍然报“打开文件过多”。终端与服务可能由不同父进程启动，继承的限制也不同。排查应落到实际进程，而不是拿当前 shell 的读数替它作证。

本文给出配置核对顺序，并在本任务自建子进程中演练描述符耗尽。实际实验运行于 macOS，没有部署或修改 Linux 服务，也没有改变当前会话的限制。

软限制负责执行，硬限制约束可调整范围

Linux getrlimit(2) 区分软限制与硬限制。对 RLIMIT_NOFILE，它约束可用描述符编号范围；打开、复制或建立管道等操作超出限制时，可能得到 EMFILE。

不要直接把限制值减去当前文件数就当成精确余量。描述符不只对应普通文件，还包括套接字、管道等；编号分配、继承和并发打开也会影响结果。系统级资源耗尽与单进程限额也需要通过错误码和上下文区分。

对于 systemd 管理的服务，可以核对片段：

[Service]
LimitNOFILE=1024:4096

这是软限制与硬限制的示例，不是本文推荐的默认值。具体语法与继承条件查systemd.exec。实际部署要结合程序使用的 I/O 接口与正常峰值，不能见到错误就盲目调大。

配置、管理器和实际进程连起来看

对受控 Linux 实验服务，可读取管理器属性：

systemctl show demo.service -p MainPID -p LimitNOFILE -p LimitNOFILESoft

demo.service 是占位名，字段应对照目标版本。再核对对应进程的 /proc/PID/limits，必要时检查工作进程，而不只看包装脚本。服务若会派生多个工作进程，每个进程的限制与使用情况都应分别记录。

本文未执行这些 Linux 命令。配置更改、重新加载与重启也没有发生，不能据文档示例声称目标服务已经获得新限制。

只在短生命周期子进程中触发耗尽

有限实验先启动一个独立 Python 子进程，将它自己的软限制降到不高于 64，保留硬限制，然后反复打开空设备。主进程不改变限制，也不向其他任务发送信号。

核心逻辑如下，只适合专用实验进程：

import errno, os, resource

soft, hard = resource.getrlimit(resource.RLIMIT_NOFILE)
cap = 64 if soft == resource.RLIM_INFINITY else min(64, soft)
resource.setrlimit(resource.RLIMIT_NOFILE, (cap, hard))
fds = []
try:
while True:
fds.append(os.open(os.devnull, os.O_RDONLY))
except OSError as exc:
assert exc.errno == errno.EMFILE
os.close(fds.pop())
fd = os.open(os.devnull, os.O_RDONLY)
os.close(fd)
finally:
for fd in fds:
os.close(fd)

运行前提是该子进程原本有足够余量容纳示例；不要把代码贴进长期服务或交互式解释器。完整执行记录还设置了子进程超时，并检查退出状态。

本次观察到 EMFILE，关闭一个自建描述符后，再次打开成功，随后全部清理并退出。这只证明当前实验进程的限额与恢复行为，不是 Linux systemd 配置验证，也没有测出实际服务安全上限。

达到上限时，还要能保存失败信息

描述符耗尽后，程序可能连新日志文件也打不开。错误路径不应临时依赖大量新资源。可以使用已经建立的受控错误输出，并把任务状态返回给调用者，避免把“资源不足”误说成“日志不存在”。

异常回收同样重要。连接失败、解析失败、取消请求都要归还已打开资源；提高上限只能延后泄漏暴露。建议把重复任务后的使用量与稳定基线比较，再决定是否需要增加容量。

用 select 的程序还有额外兼容边界，不能只提升限制而忽略它可处理的描述符范围。是否改用其他机制，取决于程序与平台，本文没有做相关迁移或高编号实验。

配额是保护条件，不是容量规划答案

默认值需要结合并发任务、每项占用和保留余量决定。采集器、模型服务和导出流程可能使用不同资源，不必都套同一个数。运行观察应记录限制、实际峰值、失败点和回收后是否恢复。

如果只是偶发打开失败，先保留错误码与资源账，再区分单进程上限、系统资源、权限和路径问题。证据不足时直接修改上限，可能掩盖真正的生命周期缺陷。

资料与验证范围

• 官方依据：getrlimit(2)、systemd.exec。
• 已执行：自建 macOS 子进程中的软限制耗尽、EMFILE、关闭一个后恢复打开与清理；父会话限制未修改。
• 未执行：Linux 服务配置、/proc 观测、长期泄漏、select 高编号兼容、浏览器、真实 API 和生产构建。没有容量推荐值。