当你执行ulimit -c命令进行查看时，如果返回结果为0，就表示当前 shell 会话中的 core dump 核心转储功能已经被禁用，也就是说程序崩溃后不会生成任何 core 文件。那么，Linux 怎么查看 core 文件保存位置呢？这时就需要结合/proc/sys/kernel/core_pattern这个文件来判断，确认系统是直接指定了 core 文件存储路径，还是交由systemd-coredump统一管理。如果属于 systemd-coredump 管理模式，可以通过coredumpctl命令查看相关核心转储信息。
ulimit -c 输出为 0 就表示已禁用 core dump
直接执行 ulimit -c 是判断 Linux 核心转储是否开启的最快方法。输出的数字表示当前 shell 会话允许生成的 core 文件最大字节数；如果结果是 0，说明在该会话下，任何进程发生崩溃都不会生成 core 文件。这并不是“找不到 core 文件”，而是压根没有开启该功能——很多生产环境服务器默认值就是 0。
需要注意的是，ulimit -c 只能反映当前 shell 的资源限制，并不完全代表整个系统的全局状态。虽然子进程通常会继承这个值，但其他登录会话、systemd 启动的服务以及容器中的进程，往往可能拥有各自独立的限制配置。
/proc/sys/kernel/core_pattern 决定 core 文件存储位置和命名方式
通过运行 cat /proc/sys/kernel/core_pattern，可以查看 Linux 内核当前实际采用的 core 文件路径模板。常见输出一般包括：
core：默认行为，表示写入当前工作目录，文件名固定为core/var/core/core.%e.%p：表示写入指定目录，并按程序名和 PID 进行命名|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h：表示通过 systemd-coredump 管道处理，此时通常不会直接生成普通 core 文件，需要使用coredumpctl查询
如果你看到输出内容前面带有管道符 |，就不要再去文件系统里盲目查找 core 文件了——此时正确的排查入口应该是 coredumpctl list。
limits.conf 里的 * soft core unlimited 不一定已经生效
即便你已经在 /etc/security/limits.conf 中配置了：
* soft core unlimited* hard core unlimited
也仍然需要进一步确认以下两点：
- 用户是否已经重新登录系统（例如重新连接 SSH 或重新登录图形界面），否则新的限制参数不会被加载
- 服务是否由 systemd 启动：如果是 systemd 管理的服务，通常不会直接采用 limits.conf，需要在 service 文件中显式配置
LimitCORE=infinity
验证方法是：先启动一个测试进程（例如 sleep 1000 &），然后执行 cat /proc/$(pidof sleep)/limits | grep core，查看该进程实际获得的 core limit 限制值。
在 systemd 系统中，coredumpctl 比直接找 core 文件更可靠
在较新的 Linux 发行版中（如 Ubuntu 16.04+、CentOS 8+、RHEL 8+ 等），systemd-coredump通常默认启用。此时，core 文件一般会被压缩后存放到/var/lib/systemd/coredump/目录，并按照 UID、时间戳等信息建立索引。单纯手动查看这个目录时，往往容易遗漏关键信息，因此更推荐优先使用以下命令：
coredumpctl list —— 列出系统中所有已捕获的崩溃记录coredumpctl info myapp —— 查看指定程序最近一次崩溃的详细信息coredumpctl debug myapp —— 自动调用 gdb，并加载对应的二进制文件和调试符号
相比手动执行 gdb ./myapp core，这种方式会自动处理路径、权限以及符号匹配等问题，能够显著减少排查过程中踩坑的概率。
很多时候，真正棘手的问题并不是“Linux 怎么开启 core dump”，而是“明明已经开启了，却还是找不到 core 文件”。常见原因通常包括：保存路径设置不正确、目录权限不足、被 systemd 接管处理，或者服务运行在容器环境中但没有正确透传 ulimit。排查时，建议先重点确认 ulimit -c 和 core_pattern 这两个关键点，再决定下一步是去文件系统中查找，还是通过 coredumpctl 获取核心转储信息。
