ohasd.bin 启动卡住时应先删除残留的 /var/tmp/.oracle/npohasd 管道文件再执行 crsctl start crs需确认目录权限正确、检查 ohasd.log 与 ocssd.log 中超时及磁盘识别问题并验证 crsctl check has 状态是否为 online。ohasd.bin 启动卡住时先看 /var/tmp/.oracle/npohasd 是否残留oracle 11g rac尤其是 11.2.0.4启动失败最常见的表象是 crsctl start crs 卡住、无输出ps -ef | grep ohasd.bin 显示进程存在但状态僵死日志里反复出现 timed out waiting for ohasd monitor。这不是配置错误而是启动机制被一个 unix 命名管道文件阻塞了。/var/tmp/.oracle/npohasd 是 ohasd.bin 启动时创建的 IPC 通信通道正常启动后由 monitor 进程接管若上次异常退出未清理新进程会尝试读取该管道并无限等待直接删掉它rm -f /var/tmp/.oracle/npohasd再执行 crsctl start crs90% 以上能立刻恢复注意权限该目录属 root:root普通用户删不掉且不能只删 npohasd 而留空目录——/var/tmp/.oracle/ 必须存在且权限为 drwxr-xr-x确认 ohasd 是否真在运行别被 ps 的假象骗了ps -ef | grep ohasd.bin 看到进程号 ≠ 它在正常工作。真正要验证的是它的子进程链和监控状态。用 crsctl check has 查真实状态返回 CRS-4638: Oracle High Availability Services is online 才算成功若报 CRS-4639: Could not contact Oracle High Availability Services说明 ohasd 根本没活过来检查 ohasd.log路径$GRID_HOME/log/hostname/ohasd/ohasd.log重点搜 OHASD00117 和 reboot 字样——前者是超时标志后者说明进程被强制重启过但失败不要依赖 systemctl status oracle-ohasdRHEL7 上可能显示 active但实际内部已 hangohasd 是 init 进程PID 1 的子进程它不走 systemd 生命周期管理从 ocssd 日志反推依赖链断裂点ohasd 启动后按固定顺序拉起 cssd → crsd → evmd → asm。一旦卡在中间ocssd.log 是第一个暴露问题的现场。查 $GRID_HOME/log/hostname/cssd/ocssd.log看最后几行是否卡在磁盘发现阶段例如反复打印 Fetching UFS disk :/dev/raw/raw1: ——这说明 ASM 磁盘路径不可达或权限不对cssd 无法完成集群成员资格校验后续全部阻塞常见诱因/dev/raw/* 设备消失UDEV 规则失效、ASM 磁盘权限不是 grid:asmadmin、OCR/Voting Disk 所在磁盘未被识别此时别急着重启整个集群先手动跑一遍磁盘扫描udevadm trigger ls -l /dev/raw/ 确认设备存在再试 crsctl start crs为什么 crond 会被牵连它其实只是背锅侠标题里提到 crond但它和 RAC 启动挂起基本无关——除非你误把 GI 自动启动脚本加进了 crontab或者 crond 自身崩溃导致系统级定时任务紊乱极罕见。 Bolt.new Bolt.new是一个免费的AI全栈开发工具