Core文件位置由/proc/sys/kernel/core_pattern决定，需结合ulimit -c是否启用、file命令确认进程来源，并注意SIGKILL等信号不会生成core文件。
Core文件在哪？先确认路径和生成开关
oracle rac节点重启后若留下core.*文件，说明内核触发了崩溃转储（core dump），但默认可能被禁用或重定向。关键不是“有没有”，而是“会不会写、写哪去”。
-
/proc/sys/kernel/core_pattern决定位置和命名规则，常见值如/var/core/core.%e.%p或/home/backup/crash/core-%e-%u-%p-%s-%t—— 必须按该路径去找，不能只扫$ORACLE_HOME - 若路径含变量（如
%e表示可执行文件名），用file /path/to/core.*才能确认它属于哪个进程，比如输出含from 'crsd.bin'就指向集群资源管理进程 - 检查
ulimit -c：如果是0，说明当前 shell 环境禁止生成 core；但 RAC 后台进程（如crsd.bin）由 init 脚本启动，其限制看/etc/init.d/init.cssd或 systemd service 文件里的LimitCORE设置
怎么确认是哪个进程崩溃的？别只看文件名
Core 文件本身不带进程上下文，仅靠 core.12345 这种命名无法判断来源。必须结合时间戳和进程生命周期交叉验证。
- 查
messages或/var/log/syslog中崩溃前后 5 分钟内是否有kernel: traps:、segfault at或aborted (core dumped)记录，匹配时间点 - 用
find /u01 -name "core.*" -newermt "2026-06-14 06:50" ! -newermt "2026-06-14 07:05" -ls锁定重启窗口内的 core 文件 - 运行
file /path/to/core.xxx，输出里明确写有from 'ocssd.bin'或from 'oprocd.bin'才算实锤 —— 千万别凭目录名（如/crs/log/rac1/crsd/）直接下结论
gdb调试前必须核对三件事
拿 gdb 开 debug 不是目的，定位崩溃根源才是。跳过下面任意一项，gdb 只会显示 No symbol table info available 或一堆无意义地址。
- 确保你用的是**同一版本、同编译参数**的二进制：比如崩溃的是
/u01/grid/19.0.0/bin/ocssd.bin，就绝不能拿/u01/grid/12.2.0/bin/ocssd.bin去加载 core - 确认对应版本的 debuginfo 包已安装：
rpm -q oracle-grid-debuginfo（RHEL）或检查$ORACLE_HOME/lib/libclntsh.so.*是否带调试符号 - 运行
gdb /path/to/binary /path/to/core后，立刻输bt full，重点看最顶层帧是否含clssscExit、GMClientListener或sigprocmask—— 这些是 RAC 崩溃高频调用点，而非泛泛的__libc_start_main
为什么有时找不到 core？因为根本没生成
很多 RAC 节点重启后查不到 core.*，不是漏找了，而是系统压根没写。这不是配置问题，是设计使然。
- 当
ocssd.bin因心跳超时被强制 kill（signal 9），内核不会产生 core ——SIGKILL无法被捕获，更不会触发 dump - 如果重启源于
oprocd的硬件级干预（如 CPU soft lockup 检测），整个 kernel space 已不稳定，core 写入可能被中断或丢弃 - HP-UX 或 AIX 上，需额外启用
vmtune -p或chdev -l sys0 -a enhanced_core_dump=true，Linux 默认行为也不保证每次 segfault 都落盘
真正可靠的线索不在 core 文件，而在 $GRID_HOME/log/<node>/cssd/ocssd.log</node> 末尾几行 —— 出现 clssscExit: CSSD signal 11 或 misscount exceeded 时，即使没 core，也已锁定根因方向。
