crs-2674 是 cssd 启动链断裂的结果，非 cssd 自身崩溃，而是其前置依赖（ora.diskmon、ocr/voting disk 可访问性、私网子网一致性、节点时间同步）未满足所致；必须回溯验证这三项硬条件并清理残留状态后再重试 root.sh。
CRS-2674 启动失败不是单一错误，而是 CSSD（Cluster Synchronization Services Daemon）启动链断裂的最终表现；必须回溯到 ora.diskmon 和 ora.cssd 的前置依赖是否就绪，不能只盯着报错行。
为什么 crsctl start crs 报 CRS-2674 却说 “CSSD failed”？
这不是 CSSD 自身崩溃，而是它启动前就被卡死在资源校验环节。典型路径是：ora.diskmon 先起成功 → CSSD 尝试读 OCR/voting disk → 发现磁盘不可用、权限不对、ASM 未就绪或私网子网不匹配 → 直接退出并报 CRS-2674。
常见诱因包括：
-
ora.diskmon虽显示 succeeded，但实际没真正探测到 voting disk（比如 ASM 磁盘组 offline、udev 规则未生效、多路径设备名漂移） - OCR 文件所在磁盘组未挂载，或挂载路径权限非
grid:oinstall - 私网配置污染：用
oifcfg setif改过子网，但物理网卡 CIDR 仍为旧值（如配置了10.10.12.0，而ip addr show eth1显示的是10.10.11.61/24） - 节点时间不同步（>500ms），CSSD 拒绝加入集群
ora.cssd 启动前必须验证的三项硬条件
别跳过这三步直接重跑 root.sh 或重启服务器——它们是 CRS 启动的闸门：
- 确认 voting disk 可访问：
crsctl query css votedisk输出应有有效路径；若报 “no voting files”，说明diskmon没识别到任何候选盘，需查asmcmd lsdg和ls -l /dev/oracleasm/disks/ - 验证私网连通性与子网一致性：
oifcfg getif返回的 subnet 必须和ip addr show eth1 | grep inet输出的网络地址（如10.10.11.0/24）完全一致，包括斜杠后掩码位数 - 检查时间同步：
ntpq -p在所有节点执行，确保 offset ≤ 500ms；若用 chrony，确认chronyc tracking中 stratum 正常且 no sync source
root.sh 卡在 CRS-2674 时的应急操作顺序
这是安装阶段最常踩的坑，强行重试只会让 OCR 元数据更脏：
- 先停掉已半启动的 CRS：
crsctl stop crs -f（不是stop cluster，后者要求 CSSD 已运行） - 清理残留状态：
/u01/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig -force（注意路径，别用roothas.pl，11g 不适用） - 手动验证物理网卡配置：改
/etc/sysconfig/network-scripts/ifcfg-eth1，确保IPADDR和NETMASK匹配你计划使用的私网子网 - 同步更新
/etc/hosts，私网 IP 必须解析到对应主机名（不能只写 loopback） - 最后再跑
root.sh，全程盯/u01/app/11.2.0/grid/install/root_*.log，重点搜cssd和diskmon关键字
真正麻烦的从来不是报错本身，而是报错前那几秒里 diskmon 静默失败、OCR 校验被跳过、私网 ARP 缓存未刷新这些“看不见”的环节。盯日志比背命令重要，看 ip addr 比信 oifcfg getif 可靠。
