CLSRSC-119本质是OLR初始化阻塞，常见于olr.loc路径不可写、/dev/shm空间不足或SELinux拦截；需查rootcrs.log、验证olr路径可写性、时间同步及shm大小（SLES 12 SP3需≥4G）。
CLSRSC-119 是 Oracle 12c RAC 执行 root.sh 时非常典型的卡点错误，本质不是脚本挂起，而是集群资源注册或 OCR 访问被阻塞，进程在后台静默等待超时（默认约 30 分钟）。直接杀进程重试只会复现问题。
root.sh 卡在 CLSRSC-119 的常见触发场景
CLSRSC-119 日志行通常紧随 ConfigOLR 或 SetupLocalGPNP 步骤之后出现，例如：
2019/01/26 01:12:49 CLSRSC-594: Executing installation step 9 of 19: 'ConfigOLR'. 2019/01/26 01:13:22 CLSRSC-119: Waiting for the OLR to be initialized...
这说明脚本已进入本地 OCR（OLR）初始化阶段，但无法完成写入或校验。
- 节点上存在残留的
/etc/oracle/olr.loc文件，且指向一个不可写、不存在或权限错误的设备路径 -
/u01/app/grid/cdata（或类似路径）目录被占用或磁盘满，导致 OL R 初始化失败 - 系统时间不同步（误差 > 1 秒），GPNP profile 校验失败，
root.sh在等待 NTP 稳定（实际不等，只是反复重试） - SELinux 处于
enforcing模式，拦截了ohasd对/dev/shm或/var/tmp/.oracle的访问 - 使用 NFS 挂载的共享路径存放 GRID_HOME，而 NFS 服务器禁用了
noac或hard,intr选项，导致元数据操作卡住
如何快速定位卡点根源
不要靠猜，直接查三处日志和状态：
- 查看完整日志路径（
root.sh输出里明确写了）：/oracle/app/grid/crsdata/WWJD-DB1/crsconfig/rootcrs<em>WWJD-DB1</em>*.log，搜索关键词OLR、gpnptool、permission denied、No such file - 检查 OLR 位置是否可写：
cat /etc/oracle/olr.loc→ 得到olrconfig_loc=路径 →ls -ld /path/to/olr+touch /path/to/olr/test.$$ && rm /path/to/olr/test.$$ - 验证时间同步：
ntpq -p（必须有有效远程源）、date（所有节点误差 ≤ 0.5 秒）
RHEL/SLES 上最常漏掉的修复动作
- 清理旧 OLR 痕迹（尤其重试安装时）：
rm -f /etc/oracle/olr.loc rm -rf /u01/app/grid/cdata/*
- 强制关闭 SELinux（别只设
permissive）：setenforce 0+ 修改/etc/selinux/config中SELINUX=disabled，必须重启生效 - 确保
/dev/shm挂载参数不含noexec：mount | grep shm应显示rw,nosuid,nodev，否则重新 mount：umount /dev/shm mount -t tmpfs shm /dev/shm
容易被忽略的细节：SLES 12 SP3 特定坑
SLES 12 SP3 内核（如 4.4.162-94.69.2）对 tmpfs 的 size= 参数敏感。若 /dev/shm 挂载时指定了过小 size（如 size=2G），而 GRID 安装需要 ≥ 4G，root.sh 就会在 OLR 初始化阶段因空间不足静默卡死 —— 日志里不会报错，只停在 CLSRSC-119。
检查命令：df -h /dev/shm；修复方法：mount -o remount,size=8G /dev/shm，并写入 /etc/fstab。
真正的难点从来不在“怎么装”，而在“为什么它以为自己卡住了却不说清楚”。CLSRSC-119 就是这样一个沉默的守门人：它不报错，只等你主动交出正确的环境状态。
