最直接方法是查看/proc/sys/kernel/core_pattern：若以|开头（如|/usr/lib/systemd/systemd-coredump），则由systemd接管，需用coredumpctl查询；若为纯路径（如/var/crash/core.%e.%p.%t），则写入对应目录，但须确保目录存在且权限正确（如1777），同时ulimit -c必须非零，否则内核不触发dump。
看 /proc/sys/kernel/core_pattern 是最直接的方法
这个文件决定了 core dump 文件最终写到哪、叫什么名。它不是“建议”，而是内核实际执行的规则，优先级高于任何其他配置。
运行 cat /proc/sys/kernel/core_pattern，结果可能有两类：
- 以
|开头（例如|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e）：说明 systemd 接管了 dump 捕获，不会落盘为普通文件，得用coredumpctl查； - 纯路径（例如
/var/crash/core.%e.%p.%t或core）：前者表示绝对路径，后者表示相对路径——即程序崩溃时的当前工作目录。
注意：core_pattern 里出现的变量如 %e（程序名）、%p（PID）、%t（时间戳）会在生成时被替换，所以你看到的“路径”其实是模板，不是最终文件名。
systemd 系统下别在文件系统里瞎找 core
如果你的系统跑的是 systemd（绝大多数现代发行版都是），且 core_pattern 以 |/usr/lib/systemd/systemd-coredump 开头，那 dump 根本不写进文件系统——它被 systemd-coredump 进程收走，存进二进制数据库里。
这时你要用这些命令：
-
coredumpctl list：列出所有已捕获的 dump（按时间倒序）； -
coredumpctl info <code>myapp或coredumpctl info <code>12345：查某个程序或 PID 对应的 dump 元信息，包括存储位置（通常是/var/lib/systemd/coredump/下的加密 blob）； -
coredumpctl dump <code>myapp--output core.myapp：把 dump 导出为标准 ELF 格式文件，供gdb使用。
常见错误：在 /tmp 或程序目录下 ls core* 找不到，就以为没生成——其实它就在 coredumpctl list 里躺着。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
ulimit -c 为 0 时，core_pattern 再对也没用
这是最容易被跳过的前置检查。即使 core_pattern 配得再规范，只要当前 shell 的 ulimit -c 是 0，内核压根不会触发 dump 生成流程。
验证和修复方式：
-
ulimit -c输出0→ 表示禁用，需先运行ulimit -c unlimited（仅当前 shell 生效）； - 若要永久生效，改
/etc/security/limits.conf，加两行：* soft core unlimited* hard core unlimited； - 注意：systemd 服务默认忽略
limits.conf，必须在 service 文件里显式写LimitCORE=infinity才行。
手动测试 dump 是否真能落地，比看配置更可靠
配置都对了？不一定。最稳妥的方式是亲手触发一次段错误，然后立刻验证。
三步操作：
- 确保
ulimit -c非零，且core_pattern指向一个**真实存在且可写**的目录（比如/tmp/core.%e.%p）； - 运行
kill -SEGV $$（对自己当前 shell 发送 SIGSEGV）； - 立刻检查：
— 如果core_pattern是绝对路径，去对应目录看有没有新文件；
— 如果是core，就ls -l core看当前目录；
— 如果走 systemd，就coredumpctl list | head -n3看最新一条是否匹配时间。
关键细节：路径里的目录必须提前 mkdir -p 创建好，否则内核静默失败——连日志都不记。
