srvctl stop crs失败后ps仍见进程，因crs守护进程（ohasd/crsd/cssd）卡死、asm实例hang住或os孤儿进程脱离crs管理，导致crsctl失去控制权，需先软杀再清缓存和ipc资源。
gi（grid infrastructure）无法正常 shutdown，不是“没关干净”，而是部分进程已脱离 crs 管理但仍在 os 层存活 —— 直接 kill -9 不是兜底方案，而是必须前置确认的步骤。
为什么 srvctl stop crs 失败后，ps -ef | grep ora 仍有一堆进程？
CRS 停止失败时，常见现象是 crsctl check crs 报 CRS-4638: Oracle High Availability Services is online，但实际 crsctl stat res -t 显示大量资源为 OFFLINE 或 UNKNOWN。此时 srvctl 和 crsctl 已失去对底层进程的控制权，原因包括：
- CRS daemon（
ohasd、crsd、cssd）因信号阻塞或共享内存损坏卡死，无法响应 shutdown 指令 - ASM 实例或数据库实例在 shutdown 过程中 hang 住，未释放其关联的
ora_<xxx>_asm</xxx>或ora_<xxx>_rac</xxx>进程 - OS 层存在孤儿进程（orphaned process），例如被
fork()启动但父进程已退出，导致 init（PID 1）接管，不再受 CRS 生命周期管理
如何精准定位并 kill GI 残留进程（不误杀 DB 进程）？
关键在于区分 CRS 进程与普通 Oracle 数据库进程。GI 进程统一由 grid 用户启动，且路径固定在 $ORACLE_HOME/bin/ 下；而数据库实例进程由 oracle 用户启动，路径为 $ORACLE_HOME/rdbms/ 或 $ORACLE_HOME/bin/oracle。执行以下命令前，请确保已切换至 grid 用户：
- 查 CRS 主进程：
ps -eo pid,user,args | grep -v grep | grep 'ohasd\|crsd\|cssd\|evmd\|gpnpd\|mdnsd' - 查 ASM 实例相关进程：
ps -eo pid,user,args | grep -v grep | grep 'asm_pmon\|asm_vktm\|asm_diag' - 查监听和 SCAN 相关进程：
ps -eo pid,user,args | grep -v grep | grep 'tnslsnr.*LISTENER|tnslsnr.*SCAN' - 避免误杀：跳过所有含
oracle $ORACLE_HOME/rdbms/或oracle $ORACLE_HOME/bin/oracle的行
kill 顺序和信号选择有讲究
不能一上来就 kill -9。先尝试软终止，再逐级升级：
- 对
ohasd、crsd、cssd等守护进程，优先发SIGTERM（默认kill不带参数）：等待 30 秒看是否退出 - 对 ASM 实例进程（如
asm_pmon），可尝试kill -15；若 10 秒无响应，再用kill -9 -
绝对禁止对
cssd单独发-9：它负责节点心跳，强杀可能导致 Voting Disk 仲裁异常，引发节点驱逐（Node Eviction） - 确认所有目标进程 PID 后，批量 kill：
kill -15 $(ps -eo pid,args | grep 'crsd\|cssd' | grep -v grep | awk '{print $1}')
清理完进程后，必须擦除残留状态文件
仅 kill 进程不够。CRS 重启失败常因状态文件未清除，导致新进程读到脏状态而拒绝启动：
- 删除 OCR/Voting Disk 缓存：
rm -f /u01/app/19.0.0/grid/cdata/*（路径依$GRID_HOME调整） - 清空 CRS 日志缓存：
rm -f /u01/app/19.0.0/grid/log/*/alert*.log - 移除 IPC 资源：
ipcs -q | awk '$5 ~ /grid/ {print $2}' | xargs -I{} ipcrm -q {}（只删 grid 用户的 message queue） - 特别注意：
/tmp/.oracle和/var/tmp/.oracle必须清空，否则新cssd启动时会因 socket 文件冲突失败
最易被忽略的是 CSSD 的 socket 文件残留和 Voting Disk 的 ASM disk header 污染 —— 这两者不会在 ps 里体现，但足以让 crsctl start crs 卡在 “Waiting for CSS daemon to start” 阶段。动手前务必确认 ls -l /tmp/.oracle 为空，且 dd if=/dev/zero of=/dev/asm_vote1 bs=1024 count=1（仅限测试环境）这类操作是否已被评估风险。
