ohasd.bin 启动卡住90%以上因/var/tmp/.oracle/npohasd残留导致，需root删除该文件并确认目录权限，再执行crsctl start crs；真实状态须以crsctl check has返回CRS-4638为准，而非ps或systemctl显示。
ohasd.bin 启动卡住，90% 以上是 /var/tmp/.oracle/npohasd 管道文件残留导致的假死，删掉就能恢复；别被 ps -ef | grep ohasd.bin 显示的进程号骗了，那只是僵死的僵尸进程。
删掉残留的 npohasd 管道文件再重启 CRS
oracle 11g/12c/19c rac 在异常退出后，ohasd.bin 创建的 ipc 通道 /var/tmp/.oracle/npohasd 往往没被清理。新启动时它会阻塞在管道读取上，无限等待——不是配置错，是机制卡死。
-
rm -f /var/tmp/.oracle/npohasd（必须用 root 执行） - 确认
/var/tmp/.oracle目录存在且权限为drwxr-xr-x，属主root:root - 执行
crsctl start crs，不要加-init参数 - 5 秒内没反应就立刻 Ctrl+C，别干等
验证 ohasd 是否真在线，而不是 ps 的幻觉
ps 看到进程 ≠ 它在工作。真正能说明问题的是监控状态和子进程链。
- 运行
crsctl check has：返回CRS-4638: Oracle High Availability Services is online才算成功 - 若报
CRS-4639: Could not contact Oracle High Availability Services，说明ohasd根本没活过来 - 别信
systemctl status oracle-ohasd，RHEL7+ 上它常显示 active，但内部已 hang - 检查
$GRID_HOME/log/<hostname>/ohasd/ohasd.log，搜OHASD00117（超时标志）或reboot（被强制重启过）
从 ocssd.log 反推磁盘识别失败这个根因
ohasd 启动后顺序拉起 cssd → crsd → evmd → asm。一旦卡住，ocssd.log 是第一个暴露问题的日志。
- 路径：
$GRID_HOME/log/<hostname>/cssd/ocssd.log - 重点看最后几行是否反复打印类似
Fetching UFS disk :/dev/raw/raw1: - 常见诱因：
/dev/raw/*设备消失（UDEV 规则失效）、ASM 磁盘权限不是grid:asmadmin、OCR/Voting Disk 所在磁盘未被识别 - 先手动触发扫描：
udevadm trigger && ls -l /dev/，再检查ls -l /dev/oracleasm/或ls -l /dev/mapper/下 ASM 设备是否存在
别漏掉 systemd 的 DefaultTasksMax 限制
Linux 7.6+ 上，DefaultTasksMax=512 会直接导致 fork() 失败，表现为 ora.crsd 启动失败、srvctl 无响应、告警日志里出现 ORA-27300: OS System Dependent Operation: fork failed with status: 11。
- 查当前值：
systemctl show --property DefaultTasksMax - 编辑
/etc/systemd/system.conf，取消注释并设为：DefaultTasksMax=infinity - 必须重启主机才生效，
systemctl daemon-reload不起作用 - 该参数影响系统级
max_pid，Oracle RAC 进程树深度远超默认 512 限制
/var/tmp/.oracle/npohasd 是最表层的“症状”，但背后可能连着 UDEV 规则失效、DefaultTasksMax 限制、OCR 磁盘权限错误三重陷阱。每次删完管道文件就以为修好了，下次还挂——得顺着 ocssd.log 和 systemctl show 一起查，否则只是治标。 
