ulimit -c 输出0即禁用core dump，表示当前shell会话禁止生成core文件；需同步检查/proc/sys/kernel/core_pattern路径配置、systemd-coredump状态及fs.suid_dumpable值。
ulimit -c 输出为 0 就代表禁用 core dump
这是最直接的判断方式。在终端里执行 ulimit -c，如果返回 0，说明当前 shell 会话禁止生成 core 文件——哪怕程序真的段错误了，也不会留下 core 或 core.xxx。
注意：这个限制只作用于当前终端及其派生的子进程，新开一个终端默认还是按系统配置走。
- 输出是数字（如
1024）：表示最大允许生成的 core 文件大小（单位 KB） - 输出是
unlimited：表示不限大小，但不等于“一定生成”，还要看其他条件 - 非 root 用户改不了硬限制（
hard limit），只能调低或等于软限制（soft limit）
/proc/sys/kernel/core_pattern 决定 core 文件写哪、叫什么
执行 cat /proc/sys/kernel/core_pattern 能看到当前生效的命名与路径规则。常见情况：
-
core或core.%p：说明默认行为，文件会生成在崩溃进程的当前工作目录 -
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e %c %h %E：systemd 管理的系统（如 Ubuntu 16.04+、CentOS 8+）默认走管道交给systemd-coredump，文件实际存在/var/lib/systemd/coredump/下，且通常被 zstd 压缩 -
/var/crash/core-%e-%p-%t：自定义路径，说明管理员改过sysctl配置
如果看到带 | 的管道形式，就别去当前目录翻 core 文件了——得查 systemd-coredump 的存储位置，或者用 coredumpctl list 查。
检查 systemd-coredump 是否启用（现代发行版重点）
很多新系统根本不用传统 core 文件，而是靠 systemd-coredump 统一接管。确认它是否在运行：
- 运行
systemctl is-active systemd-coredump，返回active表示服务已启用 - 运行
coredumpctl list，能列出历史崩溃记录，说明机制正常工作 - 若
coredumpctl命令不存在，可能是没装systemd-coredump包（如 minimal CentOS 镜像）
注意：systemd-coredump 默认会忽略 setuid 程序（如 sudo、passwd），除非显式设置 kernel.core_pattern 并关闭 fs.suid_dumpable 保护——这点容易漏，导致关键程序崩溃却没日志。
真正生效要看三处配置是否一致
一个 core dump 能不能落地，是三层限制叠加的结果：
-
ulimit -c：shell 层面的软/硬限制（用户级） -
/proc/sys/kernel/core_pattern：内核决定往哪写、怎么命名（系统级） -
fs.suid_dumpable：对 setuid 程序额外加锁，默认为0，需设为2才允许转储（安全敏感）
比如你改了 sysctl，但忘了 ulimit -c unlimited，或者用了 sudo ./crashy 却没调 fs.suid_dumpable，都会静默失败——连错误提示都没有，只会看到 Segmentation fault，没有 (core dumped) 后缀。
