如何分析RAC启动挂起_crond与ohasd进程启动依赖链排查

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 crs，90% 以上能立刻恢复注意权限：该目录属 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/\/ohasd/ohasd.log），重点搜 OHASD00117 和 reboot 字样------前者是超时标志，后者说明进程被强制重启过但失败不要依赖 systemctl status oracle-ohasd（RHEL7+ 上可能显示 active，但实际内部已 hang）；ohasd 是 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全栈开发工具