根本原因是pam_limits.so未被正确加载或顺序错误，导致limits.conf配置不生效；需检查PAM配置文件是否包含session required pam_limits.so，并确保SSH、su等登录方式均触发该模块。
为什么 ulimit -n 显示的软限制没生效？
根本原因通常是 pam_limits.so 没被正确加载，或加载顺序不对 —— 即使 /etc/security/limits.conf 写对了，PAM 层不读它，配置就完全无效。
常见现象：ulimit -n 输出是 1024（默认值），但 limits.conf 里已写 * soft nofile 65536；用 su -l 切换用户后仍不变；systemd --user 服务也继承不到。
-
limits.conf只是数据文件，不自动生效 —— 它必须由 PAM 模块在登录会话初始化时解析并设置 - 关键检查点：
/etc/pam.d/common-session（Debian/Ubuntu）或/etc/pam.d/login（RHEL/CentOS）是否包含这行：session required pam_limits.so - 如果用了
session [default=1] pam_succeed_if.so user ingroup nopamlimit这类跳过逻辑，可能绕过pam_limits - SSH 登录需确认
/etc/pam.d/sshd同样加载了pam_limits.so，否则ssh会话不读limits.conf
limits.conf 的通配符和优先级怎么算？
匹配不是“第一个命中就停”，而是按规则逐条扫描、叠加应用，且用户组规则优先于用户名规则，硬限制可被更早的同类型硬限制覆盖。
-
* soft nofile 1024和myuser hard nofile 65536同时存在 →myuser的软限制仍是 1024（未显式设软限），硬限制为 65536 -
@staff soft nofile 4096+alice - nofile 8192→alice属于staff组，则最终软限取较大者（8192），硬限同理 -
-表示同时设置软硬限制，比分开写soft/hard更安全，避免软限 > 硬限导致设置失败 - 注释行必须以
#开头且独占一行；空行会被忽略；路径中不能有空格（如/path/to/file不行，得写成/path/to/file）
systemd 服务绕过 limits.conf 怎么办？
systemd 忽略 PAM limits，默认使用内核默认值（通常 1024），即使用户登录 shell 的 ulimit -n 已改，其启动的服务也不会继承。
- 对用户级服务（
--user），在~/.config/systemd/user.conf或/etc/systemd/user.conf中设：DefaultLimitNOFILE=65536 - 对系统级服务，在 unit 文件里加：
[Service]段下写LimitNOFILE=65536（支持软硬分离：LimitNOFILE=4096:65536） - 修改后必须运行：
systemctl daemon-reload（用户服务还需systemctl --user daemon-reload） - 验证方式不是
ulimit -n，而是查进程：cat /proc//limits | grep "Max open files"
为什么 ulimit -n 软限制能调高但硬限制卡死？
硬限制只能由 root 提升，普通用户最多把软限制调到当前硬限制值；若 limits.conf 中硬限制没写或写得太低，后续任何 ulimit -Hn 都无法突破。
- 检查当前硬限：
ulimit -Hn；若输出是 4096，但你想设 65536，就必须先让 root 在limits.conf中提升硬限 - root 用户自身也受
limits.conf约束 —— 所以sudo ulimit -Hn 65536无效，必须改配置再重新登录 - 某些容器环境（如 Docker）默认禁用
RLIMIT_NOFILE提权，即使宿主机设了 high limit，容器内仍受限，需启动时加--ulimit nofile=65536:65536 - 内核参数
fs.nr_open是全局上限，若它小于你设的硬限，pam_limits会静默截断 —— 查看：cat /proc/sys/fs/nr_open，必要时用sysctl -w fs.nr_open=2000000提升
改完配置别急着测，先确认登录方式是否触发 PAM（比如直接 su 可能不读 common-session），再看目标进程是否真从预期上下文启动 —— 很多问题其实出在“你以为它读了配置，其实根本没走那条链路”。
