如何排查集群守护进程OHASD无法启动_init.ohasd脚本与OS系统日志分析-Oracle-PHP中文网

ohasd启动失败主因是_init.ohasd脚本初始化检查失败且静默退出，需优先检查/etc/oracle/olr.loc格式与路径有效性、/var/tmp/.oracle写权限、selinux拦截、udev/journald服务状态及kernel.sem等内核参数。

ohasd 启动失败时，`_init.ohasd` 脚本卡住或退出，先看它干了啥

这个脚本不是直接拉起 ohasd 进程，而是做初始化检查和环境准备。它会验证 /etc/oracle/olr.loc 是否存在、读取内容是否合法、对应 ocr 设备或文件路径是否可访问，还会检查 oracle 用户对 /var/tmp/.oracle 的写权限。任何一步失败，脚本就静默退出（不报错），导致后续 ohasd 启动流程中断。

_init.ohasd 不打印日志到屏幕，也不写入 $GRID_HOME/log/<host>/ohasd/</host> —— 它的日志只在 /var/log/messages 或 journald 里留痕迹
常见现象：执行 crsctl start crs 后无响应，ps -ef | grep ohasd 查不到进程，但 systemctl status ohasd 显示 “exited” 或 “failed”
别急着改脚本，先确认 olr.loc 文件格式是否正确：必须是两行，且第二行路径不能含空格或非法字符，例如：
```
olrconfig_file=/u01/app/19c/grid/cdata/olr.ocr
```

从 `/var/log/messages` 里抓 OHASD 初始化的真实报错

系统级日志才是第一手线索。OHASD 初始化阶段依赖的内核模块加载、设备节点创建、用户资源限制等，都会在这里留下明确错误。用 grep -i "ohasd\|ora\|grid" /var/log/messages 往往比翻 $GRID_HOME/log 更快定位根因。

典型错误：ORA-15042: ASM disk "X" is missing 表示 olr.loc 指向的 OCR 设备不可见，需检查 ls -l /dev/asm* 和 udev 规则是否生效
权限问题常表现为：open(/var/tmp/.oracle/sOHASD_UI_SOCKET) failed: Permission denied，说明 oracle 用户无法在 /var/tmp/.oracle 下创建 socket 文件
SELinux 启用时，即使权限看着对，也可能被拦截，查 ausearch -m avc -ts recent | grep ohasd

检查 `ohasd` 依赖的 OS 级服务和内核参数

OHASD 不是独立进程，它强依赖 udev、syslog（或 journald）、以及几个关键内核参数。这些服务没起来或参数未调优，_init.ohasd 就会在预检阶段直接放弃。

必须运行的服务：systemctl is-active systemd-udevd 必须为 active；systemctl is-active rsyslog 或 systemd-journald 必须活跃
关键内核参数缺失会导致启动失败：kernel.sem 至少要 250 32000 100 128，fs.aio-max-nr 推荐设为 1048576，否则 _init.ohasd 会跳过启动
检查命令：sysctl -a | grep -E "(sem|aio-max-nr|file-max)"，对比 Oracle 文档要求值

手动运行 `_init.ohasd` 并捕获标准错误输出

默认情况下它被 systemd 或 init 启动，stdout/stderr 被重定向，看不到实际失败点。最有效的方式是切到 root 用户，手动执行并强制显示错误。

执行：su - root -c "/etc/init.d/ohasd run >/tmp/ohasd_run.log 2>&1"，然后立刻 tail -f /tmp/ohasd_run.log
注意：不要用 sh _init.ohasd 直接执行——它依赖 PATH 和 ORACLE_HOME 环境变量，必须通过 run 入口触发完整初始化链
如果看到 ERROR: Could not find the cluster registry file，说明 olr.loc 不存在或路径指向无效设备，不是 OCR 本身损坏，而是定位失败

OHASD 启动失败的复杂点在于：它把多个检查逻辑揉在一个 shell 脚本里，且失败时不抛出可识别错误码。真正要盯住的不是 OHASD 进程本身，而是 _init.ohasd 执行过程中对系统状态的“信任假设”有没有被打破——比如以为设备存在，其实 udev 规则没 reload；以为目录可写，其实 SELinux 上了锁。这些细节一旦漏掉，光看 CRS 日志只会原地打转。