ulimit -n 只影响当前 shell 及其子进程，systemd 等服务不经过 shell 初始化，故忽略该设置；真正生效需依赖 pam_limits 或 systemd 的 LimitNOFILE 配置。
执行 ulimit -n 1024 后，lsof -p $PID | wc -l 却显示进程打开了 3000+ 文件描述符——这不是 ulimit 失效，而是 pam_limits 没生效或被绕过了。
为什么 ulimit -n 设置后进程仍能打开远超限制的文件？
根本原因：当前 shell 的 ulimit -n 只影响该 shell 及其**后续 fork 出的子进程**；但很多服务（如 systemd 服务、supervisord 管理的进程、SSH 登录后直接 exec 的守护进程）**不经过 shell 初始化流程**，因此完全忽略你手动设置的 ulimit，而是依赖系统级限制策略（即 pam_limits）。
更隐蔽的情况是：即使你配置了 /etc/security/limits.conf，若 PAM 配置未启用 pam_limits.so，或启用顺序错误、匹配用户类型不对（比如用了 @group 却没加 includedir），该配置就形同虚设。
检查 pam_limits 是否真正生效的三步验证法
- 确认 PAM 配置加载了 limits 模块：
grep -r "pam_limits" /etc/pam.d/，重点看login、sshd、system-auth（RHEL/CentOS）或common-session（Debian/Ubuntu）中是否包含session required pam_limits.so—— 缺少这行，limits.conf 就不会被读取 - 确认用户登录类型匹配：SSH 登录走的是
sshdPAM 配置，GUI 登录可能走gdm或lightdm，而 systemd 服务默认**完全不走 pam_limits**（除非显式配置PAMName=） - 验证实际生效值：
cat /proc/$PID/limits | grep "Max open files"，不要信ulimit -n输出，它只反映当前 shell 的设置；必须查目标进程的/proc视图才真实
systemd 服务绕过 pam_limits 的典型表现与修复
这是最常踩的坑：你改好了 /etc/security/limits.conf，也确认 sshd 加载了 pam_limits.so，但用 systemctl start myapp 启动的服务依然无视限制。因为 systemd 默认使用自己的资源控制逻辑，不调用 PAM。
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
解决方式不是改 limits.conf，而是直接在 service unit 中声明：
[Service] LimitNOFILE=1024 # 或更细粒度： LimitNOFILESoft=1024 LimitNOFILEHard=1024
注意：LimitNOFILE 是 systemd 原生参数，优先级高于 pam_limits；且需确保 DefaultLimitNOFILE 在 /etc/systemd/system.conf 中未被设为更高值覆盖。
limits.conf 中容易被忽略的语法陷阱
/etc/security/limits.conf 看似简单，但几处细节会导致整行配置静默失效：
- 用户名/组名前后不能有空格：
myuser soft nofile 1024✅，myuser soft nofile 1024❌（部分老版 pam_limits 对多余空格敏感） - 通配符
*不匹配 root：* soft nofile 1024对普通用户有效，但 root 需单独写root soft nofile 1024 - soft/hard 限制必须成对出现才可靠：只设
soft，某些场景下 hard 会回退到内核默认值（通常是 4096 或 65536），导致 soft 实际可被提升 - 修改后必须**重新登录**或重启对应 session：已存在的登录会话、screen/tmux 会话、systemd user session 都不会自动重载 limits
真正决定进程能打开多少文件的，从来不是你在终端敲的那条 ulimit -n，而是该进程启动时所处的完整上下文——PAM 配置是否加载、systemd 是否接管、用户 session 是否重建，缺一不可。最容易漏掉的，就是以为改了 limits.conf 就万事大吉，却忘了验证目标进程的 /proc/$PID/limits。
