CRS-2674本质是资源启动失败现象，需依据报错中具体资源名（如ora.cssd、ora.gipcd）定位日志并排查真实原因，常见包括杀软拦截、集群名违规、时间不同步、权限问题及网络配置缺陷。
CRS-2674报错本质是资源启动失败，不是单一原因
CRS-2674本身只是现象，后面跟着的资源名（比如 ora.cssd、ora.qosmserver、ora.gipcd）才是关键线索。它表示集群资源管理器（CRS）尝试启动某个组件时被拒绝或中断，但不告诉你为什么——得顺着资源名往下挖。
先查具体失败的资源和日志路径
执行 crsctl check crs 和 crsctl stat res -t 看哪些资源状态是 OFFLINE 或 UNKNOWN；再用 crsctl query crs activeversion -f 确认 GI 版本是否一致。重点看报错里带的资源名，比如：
-
ora.cssd失败 → 检查$GRID_HOME/log/<hostname>/cssd/ocssd.log -
ora.qosmserver失败 → 查$GRID_HOME/log/<hostname>/qosm/qosmserver.log -
ora.gipcd失败 → 看$GRID_HOME/log/<hostname>/gipcd/gipcd.log
别只盯着 root.sh 终端输出，那些日志里才有真实堆栈和错误码（如 TCC-0002、Unexpected end of file from server）。
高频真实原因与对应动作
根据多个现场案例和 MOS 文档（如 Doc ID 2568395.1、2253718.1），以下几类最常触发 CRS-2674：
- 杀毒软件拦截：卡巴斯基等会劫持 socket 连接，导致
qosmserver启动时收不到响应。临时禁用杀软再重跑root.sh即可验证 - 集群名超长或含非法字符：Oracle 要求 cluster name ≤15 字符，仅允许小写字母、数字、短横线，且必须字母开头。检查
olsnodes -c输出和/etc/hosts中 SCAN 名是否一致 - 时间不同步：节点间 NTP 未对齐，尤其在添加新节点时，
cssd会因心跳超时拒绝加入。运行ntpq -p和date对比所有节点 - OS 权限问题：grid 用户不在
dba或oinstall组，或$ORACLE_HOME/dbs目录权限不对（常见于数据库资源启动失败时的PRCR-1079连带报错）
别跳过 pre-check 和网络配置验证
很多人直接跑 root.sh 导致失败，其实安装前就该做三件事：
- 用
runcluvfy.sh stage -pre crsinst -n node1,node2 -verbose执行完整预检，它会暴露内核参数、共享存储可见性、UDP 多播连通性等问题 - 确认私网接口（如
eth1）已绑定且无 firewall 拦截（iptables -L -n）、无 NetworkManager 干扰（systemctl stop NetworkManager） - 检查
/etc/hosts是否包含所有节点 public、private、VIP、SCAN IP，且无重复或解析异常（nslookup <scan-name>必须返回唯一 IP）
CRS-2674 的麻烦在于它像一个“症状聚合器”——同一个错误码背后可能是杀软、DNS、磁盘权限、甚至 BIOS 中 C-state 设置不当。定位时一定要从资源名切入日志，而不是凭经验瞎试。
