oracle 启动报 ora-27123 或 ulimit -n 仍为 1024，是因为 limits.conf 配置未生效于 oracle 进程；根本原因是该配置依赖 pam 的 pam_limits.so 模块，仅对 login session 生效，而 su（不带-）、systemd 服务、pam 配置缺失、soft/hard 不匹配、通配符误用或内核限制等均会导致失效。
改了 /etc/security/limits.conf，但 Oracle 启动报 ORA-27123 或 ulimit -n 显示仍是 1024？大概率不是配置写错了，而是限制根本没加载进 Oracle 进程。
为什么 limits.conf 配置不生效
limits.conf 不是“写完就生效”的全局配置，它依赖 PAM 的 pam_limits.so 模块，而该模块只对经过 PAM 认证的 login session 生效。常见失效场景包括：
- 用
su oracle（不带-）切换用户：不会触发 login shell，pam_limits.so不加载 - systemd 管理的 Oracle 服务（如
systemctl start oracle-db）：默认绕过 PAM，完全无视 limits.conf -
/etc/pam.d/login或/etc/pam.d/sshd中缺失session required pam_limits.so行 - Oracle 用户 shell 不是 login shell（例如被设为
/bin/bash但未以 login 方式启动）
limits.conf 必须成对配置 soft 和 hard nofile
Oracle 启动时读取的是 soft 值，但某些版本（19c+）会主动尝试提升到 hard 上限。如果只配 soft，进程可能卡在提升阶段失败；如果 hard ，PAM 会静默拒绝。
- 正确写法：
oracle soft nofile 65536和oracle hard nofile 65536必须同时存在 - 不能用
*通配符代替用户名：Oracle 对用户名做精确匹配，* soft nofile 65536对oracle用户无效 - 数值不能盲目拉高：内核有
/proc/sys/fs/nr_open总上限，比如设 100000 但nr_open=1048576，实际可能被截断为 1024（取决于内核版本和补丁）
验证 nofile 是否真正作用于 Oracle 进程
别信 ulimit -n 输出——那是你当前 shell 的值，不是 Oracle 后台进程的运行时限制。
- 先查 Oracle PMON 进程 PID：
ps -u oracle -o pid,comm | grep pmon - 再查该 PID 的实际限制：
cat /proc/<pid>/limits | grep "Max open files"</pid> - 输出应为类似
Max open files 65536 65536 files；若仍是1024 4096，说明 PAM 没生效或被 systemd 覆盖 - RAC 环境必须逐节点验证，不能只看一个节点
systemd 服务必须显式设置 LimitNOFILE
如果你用 systemctl 启动 Oracle（比如自定义 oracle-db.service），limits.conf 完全不起作用，必须在 service 文件里硬编码：
[Service] LimitNOFILE=65536 User=oracle Group=oinstall ...
注意：LimitNOFILE 是 systemd 的 native 机制，不走 PAM，也不依赖 login shell。漏掉这行，哪怕 limits.conf 写得再全也没用。
