<p>ulimit -n 和 ulimit -u 检查失败的直接原因是oracle用户shell启动时未加载预设值，或/etc/security/limits.conf配置未被PAM正确应用：需确认/etc/pam.d/sshd或login含session required pam_limits.so，配置格式正确（无等号、无缩进），且必须用su - oracle或重新SSH登录启用新会话；systemd环境下还需配置/etc/systemd/system/oracle.service.d/override.conf并重载服务。</p>
ulimit -n 和 ulimit -u 检查失败的直接原因：oracle 用户 shell 启动时未加载预设值，或 /etc/security/limits.conf 配置未被 PAM 正确应用
Oracle 19c 安装程序（runInstaller）在先决条件检查阶段会调用 ulimit -n（打开文件数）和 ulimit -u（最大进程数）获取当前 oracle 用户的运行时限制。它不读配置文件，只信 ulimit 命令实时输出——而这个输出取决于用户登录时 shell 是否真正加载了 limits 配置。
- 常见错误现象：明明在
/etc/security/limits.conf里写了oracle soft nofile 65536和oracle hard nofile 65536，但su - oracle -c "ulimit -n"仍返回 1024 - 根本原因不是配置没写，而是 PAM 模块未启用：
/etc/pam.d/login或/etc/pam.d/sshd缺少session required pam_limits.so这一行（RHEL/CentOS 7+ 默认已启用，但最小化安装或自定义镜像常被删） - 另一个高频坑：使用
su oracle（不带-）切换用户，会导致 shell 不读/etc/security/limits.conf——必须用su - oracle或重新 SSH 登录才生效 - Oracle 19c 要求最低值为：
nofile≥ 65536、nproc≥ 16384；注意ulimit -u对应的是nproc，不是nofile
为什么改了 limits.conf 还是不生效？验证流程必须分三步走
很多人改完配置就跑安装，结果报 PRVF-0002 或 “maximum open files check failed”。关键在于：配置是否被加载、是否被继承、是否被覆盖，三者缺一不可。
- 第一步：确认 PAM 已启用 limits —— 检查
/etc/pam.d/sshd（SSH 登录）或/etc/pam.d/login（控制台登录），确保存在且未被注释的行：session required pam_limits.so - 第二步：确认配置语法正确 ——
/etc/security/limits.conf中 oracle 行不能有空格缩进，不能混用 tab，不能写成oracle soft nofile = 65536（等号多余），正确格式是：oracle soft nofile 65536 - 第三步：确认新会话生效 —— 退出当前 oracle 终端，用
ssh oracle@localhost或su - oracle新建完整登录会话，再执行：ulimit -n和ulimit -u，两个值都必须≥要求值
systemd 环境下 ulimit 失效的特殊处理（RHEL 8+/OL 8+）
systemd 会绕过 PAM limits，直接从自己的 unit 文件读取限制。如果系统启用了 systemd（默认），仅改 /etc/security/limits.conf 是无效的。
- Oracle 用户的 shell 启动由 systemd 管理时，需额外创建
/etc/systemd/system/oracle.service.d/override.conf（目录需手动创建） - 内容为：
[Service] LimitNOFILE=65536 LimitNPROC=16384
- 然后执行：
sudo systemctl daemon-reload && sudo systemctl restart user@$(id -u oracle)（或直接重启机器） - 验证方式不变：新开
su - oracle会话后运行ulimit -n和ulimit -u
最容易被忽略的一点：Oracle 19c 的 ulimit 检查发生在 runInstaller 启动的子 shell 中，这个 shell 继承的是你当前终端的限制，而不是系统全局设置。哪怕 root 用户 ulimit 正确，oracle 用户没重登，检查照样失败。
