crsctl start crs卡在CSSD阶段报CRS-4535，本质是磁盘被udev/multipath/残留ASM实例独占锁定；需用lsof查占用、停udev/multipath、杀残留ASM进程、dd覆盖磁盘头释放句柄，并验证votedisk与OCR路径一致性及全节点状态。
crsctl start crs卡在CSSD启动阶段，报CRS-4535或“Cannot communicate with CSS daemon”
这基本是磁盘被其他进程（尤其是udev、multipath或残留asm实例）持有独占锁导致的。css守护进程启动时会尝试以excl模式打开所有候选磁盘（包括ocr和voting disk所在磁盘），一旦某个设备被os层锁定，css就无法完成仲裁初始化，整个crs直接挂起。
关键判断点：crsctl check crs 显示 CRS-4535: Cannot communicate with Cluster Ready Services，但ps -ef | grep cssd能看到cssd进程在running状态——说明它卡在open()系统调用上，没死只是僵住。
- 先查OS层谁占着磁盘：
lsof /dev/sdb1（把/dev/sdb1换成你实际的ASM磁盘路径），重点关注udev、multipathd、asm或oracle进程 - 如果是udev规则反复触发，临时停掉：
systemctl stop systemd-udevd，再udevadm control --reload-rules - 如果是multipath设备映射冲突，检查
/etc/multipath.conf是否把ASM磁盘误加入多路径组，删掉对应blacklist或devices段后重启multipathd - 确认没有残留ASM实例：用
ps -ef | grep pmon看是否有+ASM*进程，有就kill -9掉，再清/var/tmp/.oracle/下的socket文件
ASMCMD无法连接或ls命令超时，提示“ORA-15032、ORA-15027”
ORA-15027明确表示“disk is currently mounted by another ASM instance”，这是典型的磁盘被其他节点或残留实例独占的信号。即使集群已停，ASM实例可能没真正释放设备句柄。
别急着进SQL*Plus执行ALTER DISKGROUP ... DISMOUNT——如果磁盘真被锁住，这条命令自己也会卡死或报错。
- 先切到
grid用户，用asmcmd -p登录，运行lsdg；如果返回空或超时，说明ASM实例根本没起来，问题还在底层 - 强制释放磁盘锁最稳妥的方式是：在所有节点执行
dd if=/dev/zero of=/dev/sdb1 bs=1024 count=100（仅覆盖前100KB，不影响ASM元数据主体），这会踢掉OS层所有对该设备的缓存句柄 - 做完后立刻
blockdev --rereadpt /dev/sdb1刷新分区表，再partprobe /dev/sdb1同步内核 - 然后用
oracleasm scandisks（如果是Oracle ASMlib）或udevadm trigger（UDEV方式）重新识别磁盘
OCR/Voting Disk所在磁盘组显示DISMOUNTED，但crsctl replace votedisk失败
常见现象是SELECT name,state FROM v$asm_diskgroup里目标DG状态为DISMOUNTED，而crsctl replace votedisk +GRIDDG报CRS-4602。这不是命令写错，而是ASM还没真正接管磁盘控制权。
必须确保磁盘组处于MOUNTED状态且CSS能读写——光靠SQL*Plus执行ALTER DISKGROUP ... MOUNT不够，因为CSS有自己的磁盘访问路径。
- 先确认磁盘组冗余类型：
CREATE DISKGROUP时用了NORMAL REDUNDANCY，不能是EXTERNAL，否则CSS拒绝注册 - 用
sqlplus / as sysasm执行ALTER DISKGROUP griddg MOUNT后，立刻查v$asm_diskgroup，必须看到STATE = 'MOUNTED' - 检查
grid用户是否在asmadmin组里：id -nG输出里要有asmadmin，否则crsctl无权修改CSS元数据 - 最后执行
crsctl replace votedisk +GRIDDG前，加-force参数绕过部分校验：crsctl replace votedisk +GRIDDG -force
集群重启后某节点CSS反复驱逐（evicted），日志里出现“CSSDAGENT terminated with signal 11”
这说明磁盘锁虽已清除，但CSS内部状态不一致——比如一个节点认为磁盘在线，另一个节点读到的是旧的voting disk签名，导致心跳失败被踢出。
这种问题不会在crsctl start crs命令返回“successful”时暴露，要等集群运行几分钟后才显现。
- 不要只信单节点输出，必须在每个节点分别运行：
crsctl query css votedisk，确认所有节点都显示同一路径且STATE = ONLINE - 检查
ocrcheck输出里的Device/File Name是否指向同一个磁盘组，OCR和Voting Disk最好共存于同一NORMAL冗余DG，避免跨组IO竞争 - 最关键的验证动作：在所有节点执行
crsctl stop crs -f后，等待30秒，再crsctl start crs，观察5分钟内crsctl stat res -t是否全绿、无OFFLINE或INTERMEDIATE状态 - 如果仍有节点被驱逐，立即查
$GRID_HOME/log/<hostname>/cssd/ocssd.log</hostname>，搜索misscount和disk timeout相关行，大概率是存储链路延迟抖动未收敛
