Linux 文件描述符上限的 systemd 配置清单

Linux 文件描述符上限要按“谁启动进程”来配置。只在当前 shell 执行 ulimit -n，通常只影响从这个 shell 继续派生的进程；如果服务由 systemd 拉起，应该把服务级上限写进 unit 的 LimitNOFILE=，需要统一默认值时再考虑 manager 配置。这样即使重新登录或重启服务，也不会因为交互式 shell 的临时设置消失。

官方文档入口：https://www.freedesktop.org/software/systemd/man/latest/

先看清三种文件描述符上限

这份清单只处理三个层次：当前 shell 的资源限制、systemd manager 给新服务继承的默认限制、某个 service unit 的明确限制。它们不是同一个开关。

生产部署优先使用 unit 级配置，因为它把意图绑定到服务本身。不要把“当前终端里看到的值”当成“服务进程一定会得到的值”。

适用场景：服务启动方式决定配置入口

如果程序由 systemctl start my-app.service 启动，systemd 会按照 unit 和 manager 的配置建立服务进程的资源限制。此时登录 shell 里的 ulimit 并不会自动改写已经由 systemd 管理的服务。

如果是人工在终端执行二进制文件，ulimit -n 65535 可以作为本次启动前的临时设置；但它不会替代服务定义，也不会自然覆盖定时任务、容器入口或其他服务管理器的启动路径。

快速试用：给单个 systemd 服务设置 LimitNOFILE

推荐使用 drop-in，而不是直接改发行版提供的 unit 文件。下面把服务名替换成实际的 my-app.service，并将软硬限制都写成同一个值，便于排查。

# 创建目标服务的 drop-in 目录，避免直接修改发行版 unit
sudo mkdir -p /etc/systemd/system/my-app.service.d

# 写入服务级文件描述符上限；软限制和硬限制都设为 65535
sudo tee /etc/systemd/system/my-app.service.d/limits.conf >/dev/null 

这里的 daemon-reload 只负责让 manager 重新读取 unit 定义；它不会替正在运行的进程自动改限制，所以配置变更后要重启目标服务。若服务有依赖关系，按你的发布窗口决定是单独重启还是配合依赖一起重启。

和旧方案对比：什么时候配置 manager 默认值

多个由同一个 systemd manager 管理的服务都需要相同基线时，可以在 /etc/systemd/system.conf 写入 DefaultLimitNOFILE=65535。用户级 systemd manager 则对应 user.conf 的默认配置。默认值适合平台基线，但不如 unit 级配置直观。

# /etc/systemd/system.conf：只在确实需要统一基线时设置
[Manager]
# 新建服务默认继承的文件描述符上限
DefaultLimitNOFILE=65535

修改 manager 配置后需要让对应的 manager 重新读取配置，再让新启动的服务继承新值。对单个生产服务而言，unit drop-in 通常更容易审查、回滚和迁移；manager 默认值更像组织级基线，不应该用来掩盖某个服务自身的容量需求。

重载后怎么判断配置进入服务进程

先看 unit 解析出的配置，再看进程自身的限制。两处都指向目标值时，才说明配置路径和实际进程边界一致；如果只看 shell 的 ulimit，很容易误判。

# 查看 unit 解析出的 LimitNOFILE 配置
systemctl show my-app.service -p LimitNOFILE

# 读取服务主进程的实际限制；先取得 MainPID，再检查 limits 文件
main_pid="$(systemctl show -p MainPID --value my-app.service)"
if [ "${main_pid}" -gt 0 ]; then
  # /proc 反映的是该服务进程当前看到的资源限制
  grep -i 'open files' "/proc/${main_pid}/limits"
else
  # MainPID 为 0 时说明服务没有可检查的主进程
  echo 'my-app.service 当前没有运行中的 MainPID' >&2
  exit 1
fi

systemctl show 用来确认 unit 侧的解析结果，/proc//limits 用来确认正在运行的进程。若两者不一致，优先检查是否忘记 daemon-reload、是否重启到了错误的 unit、是否存在同名 drop-in 覆盖，以及服务是否由另一个 manager 或容器启动。

采用风险与最终清单

1. 先记录服务的启动者：systemd、用户 shell、容器入口还是其他 supervisor。
2. 单服务需求写在 /etc/systemd/system/.service.d/limits.conf，不要直接编辑发行版 unit。
3. 只有平台确实需要统一基线时，才使用 DefaultLimitNOFILE。
4. 修改 unit 后执行 daemon-reload，再重启服务；修改 manager 默认值后让新启动的服务重新继承。
5. 同时保留 systemctl show 与 /proc//limits 两个检查入口，方便回滚和故障定位。

最常见的误区是把 shell 的临时值、manager 的默认值和 unit 的明确值混为一谈。把上限写入真正负责启动进程的那一层，文件描述符不足的问题才会在重启后仍保持可控。

常见问题

只执行 ulimit -n 65535 为什么服务还是旧值？

因为服务可能由 systemd 独立启动，未继承当前 shell。请把限制写入对应 unit 的 drop-in，并重载、重启后再看服务进程。

LimitNOFILE 应该写一个数字还是两个数字？

可以写单值，也可以写软限制与硬限制的组合。部署清单中写成 软值:硬值 更容易表达预期边界，具体数值仍要结合程序连接数、并发模型和系统资源评估。

systemctl show 的值正确，程序仍然打开文件失败怎么办？

继续确认实际 MainPID、进程是否发生过重启、程序是否运行在容器或其他 supervisor 下，并检查是否触达了其他资源约束。不要只根据一个配置文件推断整个进程树。