最可靠方法是直接读取cat /proc/sys/kernel/core_pattern，其输出即当前内核实际生效的core dump路径或处理程序；若以|开头（如|/usr/lib/systemd/systemd-coredump），则由用户态服务接管，不生成磁盘文件。
怎么确认core_pattern当前生效的值
直接读取内核接口最可靠：cat /proc/sys/kernel/core_pattern。这个路径返回的是**当前真正起作用的配置**，不是配置文件里的注释或旧值。如果输出以|开头（比如|/usr/lib/systemd/systemd-coredump %P），说明 core 文件被重定向到一个处理脚本，根本不会落地为普通文件——这时候你用 gdb 找不到 core，不是权限或路径问题，是压根没生成。
core_pattern里带/和不带/的区别
写入的字符串是否含路径分隔符/，直接决定 core 文件存哪：
- 如果写的是
core或core.%p（不含/），core 会生成在**进程崩溃时的当前工作目录**，不是可执行文件所在目录——这点常被忽略，尤其程序调用了chdir()后，工作目录早变了 - 如果写的是
/tmp/core-%e-%p（含/），core 一定落在/tmp/下，但得确保该目录存在且进程有写权限（比如容器里没挂载/tmp，就会静默失败） -
%e、%p、%t这些占位符只在含/的路径中安全展开；纯文件名如core.%p依赖core_uses_pid开关控制是否生效
为什么echo写core_pattern有时失败
常见报错bash: echo: write error: Invalid argument或静默无反应，原因很具体：
- 没用
sudo：普通用户无法写/proc/sys/kernel/core_pattern，必须提权 - 用了重定向但 shell 权限不够：推荐用
sudo sh -c 'echo "/tmp/core-%e-%p" > /proc/sys/kernel/core_pattern'，避免管道权限丢失 - 系统启用了
systemd-coredump：它会把core_pattern设为|/usr/lib/...，此时直接echo会被拒绝，得先停掉服务或改用sysctl方式 - 容器环境：/proc/sys 是只读挂载，
echo必然失败，得在启动容器时通过--sysctl参数注入
调试前必须验证的三件事
别急着开 gdb，先确认这三项都满足，否则白忙：
-
ulimit -c输出是unlimited（不是0，也不是数字） -
cat /proc/sys/kernel/core_pattern返回的是你期望的路径格式，且不以|开头 - 目标目录（比如
/tmp/core）已存在，且崩溃进程对其有w权限（可用touch /tmp/core/test快速验证）
漏掉任意一条，gdb your_program core 都会提示No such file或not in executable format——不是命令写错了，是 core 根本没落盘。
