ohasd.bin未随系统启动的主因是/etc/rc.d/rc.local中缺失/etc/init.d/init.ohasd run调用，需手动添加并赋权；同时必须验证olr.loc有效性及ohasd.log中“successfully initialized olr”日志，否则进程将静默退出。
ohasd.bin 没有随系统启动，init.ohasd 脚本根本没被调用 —— 这是 11g rac 节点重启后“消失”在集群里的最常见原因。
检查 init.ohasd 是否已注册为系统服务
Oracle 11g RAC 不依赖 systemd 或 init.d 的标准 service 管理机制，而是靠 /etc/rc.d/rc.local 中的手动调用。若该文件里没有这行，节点开机后连 OHAS 都不起来，后续所有服务（CSSD、CRSD、ASM、DB）全卡死。
- 执行
cat /etc/rc.d/rc.local，确认存在类似这行：/etc/init.d/init.ohasd run >/dev/null 2>&1 /null & - 若不存在，直接追加（注意权限）：
echo "/etc/init.d/init.ohasd run >/dev/null 2>&1 /null &" >> /etc/rc.d/rc.local - 必须补上可执行权限：
chmod +x /etc/rc.d/rc.local - 不要只改一个节点 —— 两个节点都得检查并同步
验证 ohasd.bin 进程是否真在运行
光有脚本不等于进程活着。ps -ef | grep ohasd.bin 只能看表象；关键要看它有没有成功完成初始化，否则会卡在 reboot 状态或直接退出。
- 运行
ps -ef | grep ohasd.bin，正常应看到类似：root 12345 1 0 May14 ? 00:00:12 /u01/app/11.2.0/grid/bin/ohasd.bin reboot - 若只看到
ohasd.bin但无子进程、且$GRID_HOME/log/<hostname>/ohasd/ohasd.log</hostname>末尾反复报OHASD00117: TIMED OUT WAITING FOR OHASD MONITOR，说明它卡死了 - 此时别重启，先清残留：
rm -f /var/tmp/.oracle/npohasd /var/tmp/.oracle/s* /tmp/.oracle/s* - 再手动触发：
/etc/init.d/init.ohasd run，观察日志是否出现ohasd is starting
为什么 crsctl start crs 会失败，而 init.ohasd run 才是起点
crsctl start crs 是 CRS 层命令，它依赖 OHAS 已就绪；但 ohasd 是整个高可用栈的根进程 —— 它不起来，crsctl 就连通信 socket 都连不上，报 CRS-4124: Oracle High Availability Services startup failed 是必然结果。
-
crsctl和srvctl都是用户态工具，它们的底层通道（/var/tmp/.oracle/sOHASD_AG）由ohasd创建 - 若
/var/tmp/.oracle/下缺失sOHASD_AG或权限不对（非 root:root），crsctl直接拒绝工作 - 所以修复顺序永远是：
init.ohasd run→ 看ohasd.log→ 再crsctl check crs→ 最后crsctl stat res -t - 切勿在
ohasd未稳态时反复执行crsctl stop crs，容易留下 IPC key 冲突
真正容易被忽略的点：即使 init.ohasd run 成功，如果 /etc/oracle/olr.loc 文件损坏或指向了不存在的设备（比如 OCR 磁盘组路径写错），ohasd 会在几秒内静默退出，进程看似存在，实则已僵死。务必查 ohasd.log 开头是否有 OLR location: 行和后续的 Successfully initialized OLR。
