OHASD启动失败主因是_init.ohasd脚本初始化检查失败且静默退出，需优先检查/etc/oracle/olr.loc格式与路径有效性、/var/tmp/.oracle写权限、SELinux拦截、udev/journald服务状态及kernel.sem等内核参数。
OHASD 启动失败时，
脚本卡住或退出，先看它干了啥
这个脚本不是直接拉起 ohasd 进程，而是做初始化检查和环境准备。它会验证
是否存在、读取内容是否合法、对应 ocr 设备或文件路径是否可访问，还会检查
用户对
的写权限。任何一步失败，脚本就静默退出（不报错），导致后续 ohasd 启动流程中断。
不打印日志到屏幕，也不写入
—— 它的日志只在
或
里留痕迹
常见现象：执行
后无响应，
查不到进程，但
显示 “exited” 或 “failed”
别急着改脚本，先确认
文件格式是否正确：必须是两行，且第二行路径不能含空格或非法字符，例如：
从
里抓 OHASD 初始化的真实报错
系统级日志才是第一手线索。OHASD 初始化阶段依赖的内核模块加载、设备节点创建、用户资源限制等，都会在这里留下明确错误。用
往往比翻
更快定位根因。
典型错误：
表示
指向的 OCR 设备不可见，需检查
和 udev 规则是否生效
权限问题常表现为：
，说明
用户无法在
下创建 socket 文件
SELinux 启用时，即使权限看着对，也可能被拦截，查
检查
依赖的 OS 级服务和内核参数
OHASD 不是独立进程，它强依赖
、
（或
）、以及几个关键内核参数。这些服务没起来或参数未调优，
就会在预检阶段直接放弃。
必须运行的服务：
必须为
；
或
必须活跃
关键内核参数缺失会导致启动失败：
至少要
，
推荐设为
，否则
会跳过启动
检查命令：
，对比 Oracle 文档要求值
手动运行
并捕获标准错误输出
默认情况下它被
或
启动，stdout/stderr 被重定向，看不到实际失败点。最有效的方式是切到
用户，手动执行并强制显示错误。
执行：
，然后立刻
注意：不要用
直接执行——它依赖
和
环境变量，必须通过
入口触发完整初始化链
如果看到
，说明
不存在或路径指向无效设备，不是 OCR 本身损坏，而是定位失败
OHASD 启动失败的复杂点在于：它把多个检查逻辑揉在一个 shell 脚本里，且失败时不抛出可识别错误码。真正要盯住的不是 OHASD 进程本身，而是
执行过程中对系统状态的“信任假设”有没有被打破——比如以为设备存在，其实 udev 规则没 reload；以为目录可写，其实 SELinux 上了锁。这些细节一旦漏掉，光看 CRS 日志只会原地打转。
_init.ohasd/etc/oracle/olr.locoracle/var/tmp/.oracle_init.ohasd$GRID_HOME/log//ohasd/ /var/log/messagesjournaldcrsctl start crsps -ef | grep ohasdsystemctl status ohasdolr.locolrconfig_file=/u01/app/19c/grid/cdata/olr.ocr/var/log/messagesgrep -i "ohasd\|ora\|grid" /var/log/messages$GRID_HOME/logORA-15042: ASM disk "X" is missingolr.locls -l /dev/asm*open(/var/tmp/.oracle/sOHASD_UI_SOCKET) failed: Permission deniedoracle/var/tmp/.oracleausearch -m avc -ts recent | grep ohasdohasdudevsyslogjournald_init.ohasdsystemctl is-active systemd-udevdactivesystemctl is-active rsyslogsystemd-journaldkernel.sem250 32000 100 128fs.aio-max-nr1048576_init.ohasdsysctl -a | grep -E "(sem|aio-max-nr|file-max)"_init.ohasdsystemdinitrootsu - root -c "/etc/init.d/ohasd run >/tmp/ohasd_run.log 2>&1"tail -f /tmp/ohasd_run.logsh _init.ohasdPATHORACLE_HOMErunERROR: Could not find the cluster registry fileolr.loc_init.ohasd