ohasd进程未启动的根本原因是系统级依赖缺失：OLR文件（/etc/oracle/olr.loc）缺失或权限错误、Linux 7+下systemd与init.ohasd冲突、IPC socket残留或SELinux拦截，导致其在rootcrs.pl第443行abort，无法完成fork。
ohasd进程根本没起来，不是配置错，是系统级依赖断了
ORA-29701 或 ohasd failed to start at /u01/app/11.2.0/grid/crs/install/rootcrs.pl line 443 这类报错，本质不是数据库参数或OCR内容问题，而是 ohasd 进程压根没成功 fork 出来。它卡在 IPC 初始化、OLR 加载或 systemd/init 冲突层面，crsctl start crs 甚至都调不动——因为底层守护没活，上层命令直接失效。
/etc/oracle/olr.loc 文件缺失或权限错误
ohasd 启动第一件事就是读 /etc/oracle/olr.loc 找本地注册库（OLR）路径。如果文件不存在、内容为空、路径指向无效设备（比如裸设备已卸载），或者权限不是 root:root 且至少为 644，rootcrs.pl 就会在第 443 行 abort。
- 检查命令：
ls -l /etc/oracle/olr.loc；内容应类似olrconfig_loc=/u01/app/11.2.0/grid/cdata/rac1/olr.ocr - 若文件损坏或丢失，不能手动编辑修复，必须用
/u01/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig -force -verbose清理后重跑-init - RHEL/CentOS 7+ 上，
olr.loc路径若指向 ASM 磁盘组（如+OCR），要确认该磁盘组已 MOUNTED 且grid用户可读
Linux 7+ 系统上 systemd 与 init.ohasd 冲突
Oracle 11g RAC 的 root.sh 仍依赖 init.d 启动 init.ohasd，但 RHEL/CentOS 7+ 默认用 systemd，导致 ohasd 启动超时（CRS-0715）或被拒绝执行（status=203/EXEC）。
- 必须在运行
root.sh前，手动创建/usr/lib/systemd/system/ohas.service，不能叫ohasd.service（会和/etc/init.d/ohasd冲突） -
ExecStart必须指向/etc/init.d/init.ohasd run，不是直接调ohasd二进制 - 启用服务：
systemctl daemon-reload && systemctl enable ohas.service && systemctl start ohas.service - 验证：
ps -ef | grep ohasd有 root 进程，且systemctl status ohas.service显示 active (running)
IPC socket 文件残留或 SELinux 拦截
ohasd 需要创建 Unix domain socket（如 /var/tmp/.oracle/npohasd）用于内部通信。若上次异常退出未清理，或 SELinux 处于 enforcing 模式，socket 创建失败，就会报 Inappropriate ioctl for device。
- 强制清理：
rm -f /var/tmp/.oracle/* /tmp/.oracle/* - 临时验证 SELinux 影响：
setenforce 0，再试crsctl start ohasd；若成功，需调整策略而非永久关闭 - 对
/var/tmp/.oracle目录，确保属主为root:root，权限至少755 - 注意：有些环境需先 touch
/var/tmp/.oracle/npohasd再 chownroot:oinstall，否则dd if=/var/tmp/.oracle/npohasd of=/dev/null会因权限失败
真正麻烦的从来不是日志里那行报错，而是 ohasd 启动失败后留下的半残状态：OLR 损坏、IPC 锁残留、systemd unit 文件写错路径、SELinux 上下文混乱——这些不会在 crsctl check crs 里直接告诉你，得一层层剥开看进程、socket、权限、服务定义是否全部对齐。
