直接执行cat /proc/sys/kernel/core_pattern查看当前生效配置：若输出为绝对路径（如/var/lib/systemd/coredump/core.%e.%p），则core文件生成于该目录；若为core，则落于程序崩溃时的工作目录；若以|开头（如|/usr/lib/systemd/systemd-coredump），则需用coredumpctl命令管理，而非直接查找文件。
怎么看当前生效的 core_pattern 配置
coredump 文件到底生成到哪，完全由 /proc/sys/kernel/core_pattern 决定，不是猜、也不是默认固定路径。最直接的办法就是读它：
cat /proc/sys/kernel/core_pattern
输出可能是：
-
/var/lib/systemd/coredump/core.%e.%p.%h.%t→ 实际路径是/var/lib/systemd/coredump/，文件名带程序名、PID、主机名和时间戳 -
core→ 就生成在程序崩溃时的当前工作目录，文件名就是core -
|/usr/lib/systemd/systemd-coredump→ 表示交由 systemd 管理，不能直接找文件，得用coredumpctl
注意：sysctl kernel.core_pattern 和 cat /proc/sys/kernel/core_pattern 输出一致，但后者更权威——因为 /proc 是实时内核接口，不会受配置未加载等干扰。
为什么 find / -name "core*" 常常找不到
全局搜索容易漏掉或误报，原因很实在：
- 如果
core_pattern是管道形式（如|/usr/lib/systemd/systemd-coredump），根本不会落地为普通文件，find必然空手而归 - 权限问题：非 root 用户搜不到
/var/lib/systemd/coredump/下的文件，2>/dev/null会把“拒绝访问”错误也吞掉，让你误以为没生成 - 路径含变量（如
%e、%p）时，文件名不固定，core*可能匹配不上（比如实际是core.myapp.12345.1712345678，但你只搜core）
真要搜，先确认 core_pattern 不是管道，再用 sudo find /var -name "core.*" 2>/dev/null 锁定常见目录，比扫全盘靠谱。
systemd 系统下别绕开 coredumpctl
Ubuntu 16.04+、CentOS 8+、Fedora 等主流发行版默认启用 systemd-coredump，这时：
-
coredumpctl list列出所有已捕获的崩溃记录（含时间、UID、可执行路径） -
coredumpctl info myapp显示该程序最近一次崩溃的完整元数据，包括实际存储路径（通常是/var/lib/systemd/coredump/下某个压缩文件） -
coredumpctl dump -o myapp.core myapp把压缩的 coredump 解包成 gdb 可读的原始文件
跳过 coredumpctl 直接去文件系统里翻，大概率扑空——因为文件是 .lz4 或 .zst 压缩格式，不是裸 core。
ulimit -c 是开关，不是路径
很多人卡在“找不到文件”，第一反应是查路径，但其实第一步该确认有没有资格生成：
ulimit -c
输出 0 就代表彻底禁用，无论 core_pattern 设得多漂亮，也不会写任何文件。临时开用 ulimit -c unlimited，但要注意：
- 只对当前 shell 及其子进程有效，systemd 服务、crontab、nohup 启动的进程不受影响
- 服务类进程需在 service 文件里加
LimitCORE=infinity，否则 ulimit 设置无效 - 容器环境（如 Docker）还要额外检查
--ulimit core=-1:-1参数是否传入
路径只是结果，开关没打开，路径再明确也白搭。
