crsctl stop crs卡住因资源依赖未满足，如实例未就绪、VIP漂移失败、ASM未dismount、CSSD心跳异常或OCR/表决磁盘I/O延迟；强制用-f前须确认无业务连接、远端已停实例、ASM已dismount且CSSD仍响应，否则易损OCR或表决磁盘。
正常执行 crsctl stop crs 卡住或返回 crs-2800（资源处于中间状态）时，不能反复重试，必须先确认阻塞点，再决定是否用 -f 强制终止——否则可能损坏 ocr 或表决磁盘。
为什么 crsctl stop crs 会卡住
CRS 停止过程依赖资源逐级下线：监听器 → 实例 → ASM → CSS。任一环节未就绪（如数据库实例仍处于 starting 状态、VIP 漂移失败、ASM 磁盘组未 dismount），crsctl stop crs 就会挂起等待，而非报错退出。
常见诱因包括：
-
ora.orcl.db资源显示ONLINE INTERMEDIATE（日志中常伴CRS-2682: It is locked by 'grid'） - 节点网络心跳异常，CSSD 进程无法完成 clean shutdown
- OCR 文件被其他进程占用（如手动编辑过
ocr.loc后未释放锁） - 表决磁盘 I/O 延迟过高，导致投票超时
用 crsctl stop crs -f 强制关闭的实操要点
-f 不是“暴力杀进程”，而是跳过资源依赖检查，直接向 CRS daemon 发送 SIGTERM 并清理本地内存状态。但它不处理远端节点状态，也不修复 OCR 损坏。
执行前必须满足：
- 已确认该节点无业务连接（
netstat -an | grep :1521应为空） - 已在其他健康节点执行
srvctl stop instance -d <db_name> -i <inst_name></inst_name></db_name>，避免跨节点资源冲突 - 当前节点的 ASM 实例已明确处于
DISMOUNTED状态（sqlplus / as sysasm→select state from v$asm_diskgroup;） - 运行
crsctl check cssd -verbose，确保 CSSD 进程仍在响应（若已僵死，-f无效，需重启服务器）
命令示例：
crsctl stop crs -f
执行后立即检查：
-
ps -ef | grep -E "(crsd|cssd|ohasd)"应无残留进程 -
crsctl check crs返回CRS-4639: Could not contact Oracle High Availability Services
强制关闭后重启失败的典型原因
强行终止 CRS 后，OCR 可能残留脏数据，导致 crsctl start crs 启动失败。最常见报错是：
-
CRS-4123: Oracle High Availability Services has been started.（看似成功）但crsctl check crs显示CRS-4537为 offline —— 实际是 OHAS 启动了，CRS 层加载失败 -
OCR initialization failed（OCR 初始化失败），通常因 OCR 文件头校验失败 -
Cannot communicate with CRS daemon，多因/var/tmp/.oracle/下 socket 文件残留未清理
此时不要反复启停，应优先：
- 手工清理 IPC：
rm -f /var/tmp/.oracle/s* /tmp/.oracle/s* - 验证 OCR 完整性：
ocrcheck -local（单节点模式下） - 若 OCR 报错，从备份恢复：
ocrconfig -restore <backup_file></backup_file> - 最后才考虑重启服务器（仅当 CSSD 完全无响应时）
强制关 CRS 是“保命操作”，不是常规手段。真正棘手的是它掩盖了底层问题——比如网卡驱动 bug 导致 CSS 心跳丢包，或存储多路径切换异常引发表决磁盘 IO hang。每次用 -f 之后，必须翻 $GRID_HOME/log/<node>/cssd/ocssd.log</node> 找出最初卡点，否则下次还会重蹈覆辙。
