EVMD反复重启主因是集群底层通信异常，需先查evmd.log中gipchaLowerRecv异常，再核对双节点/etc/oracle/ocr.loc一致性、清理/tmp/.oracle/残留IPC文件，并验证cssd/gipcd状态。
EVMD进程反复重启，先看evmd.log里有没有gipchaLowerRecv异常
EVMD频繁重启最典型的日志线索就是gipchaLowerRecv: message from unrecognized node这类报错，说明节点间心跳通信失败。它不是孤立问题，而是集群底层网络或OCR状态异常的外显。直接打开$GRID_HOME/log/<hostname>/evmd/evmd.log，用grep -i "unrecognized\|fail\|exception" evmd.log快速过滤。如果看到大量gipchaLowerRecv + ret gipcretFail(1)，基本可锁定是GIPCD层无法识别对端节点——这时候别急着重启EVMD，它只是受害者。
检查OCR一致性，重点对比/etc/oracle/ocr.loc两节点内容是否一致
OCR配置不一致会直接导致EVMD启动后校验失败并退出，典型错误是Shutdown CacheLocal. my hash ids don’t match。这个错误在crsd.log里比evmd.log更早出现。必须逐字比对两个节点的/etc/oracle/ocr.loc：内容必须完全相同（包括空格、换行），且指向的OCR设备路径在ASM中真实可访问。常见坑是手动修改过一节点的文件但忘了同步另一节点，或者OCR磁盘组本身已损坏（比如asmcmd lsdg显示STATE = DISMOUNTED）。
确认/tmp/.oracle/目录是否残留旧IPC文件
EVMD依赖Unix域套接字通信，这些socket文件存在/tmp/.oracle/下。若上次异常退出未清理，新进程会因端口占用或权限冲突失败。执行ls -l /tmp/.oracle/ | grep evm，若发现sEVMD或s#evmd类文件且属主不是grid用户，直接rm -f /tmp/.oracle/s*。注意：必须在停掉CRS后操作，否则可能影响其他进程；清理后不要立即启动EVMD，而是用crsctl start crs整体拉起，让集群管理器按顺序初始化。
验证GIPCD和CSSD状态是否正常，别只盯着EVMD
EVMD本身不处理心跳，它依赖gipcd和cssd提供的底层通信能力。用crsctl check crs看整体状态，再单独查：crsctl check cluster -all、crsctl check css、crsctl check gipcd。如果cssd或gipcd任一服务异常，EVMD必然连不上。此时evmd.log里往往只有“failed to connect to CSS”之类泛泛提示，真正根因藏在$GRID_HOME/log/<hostname>/cssd/ocssd.log或gipcd.log里——尤其注意其中是否有“interface not found”或“subnet mismatch”字样，这指向私网配置错误或物理链路不通。
cssd和gipcd；改配置要双节点核对，不能只动一边；清临时文件要停服务后再动手。否则修了三天，可能只是把同一问题反复触发。 
