Linux怎么查看系统的核心转储设置

当你使用ulimit -c命令查看时，如果输出为0，这意味着当前的shell会话已经禁用了core dump功能，也就是不会生成任何core文件。那该怎么判断core文件的存储位置呢？这就需要结合/proc/sys/kernel/core_pattern这个文件来判断，看看它是指定了存储位置，还是由systemd-coredump来管理。如果是systemd-coredump管理的，你可以使用coredumpctl命令来查看相关信息。

ulimit -c 输出为 0 就表示禁用 core dump

直接运行 ulimit -c 是最快速的判断方式。输出数字代表当前 shell 会话允许生成的 core 文件最大字节数；若为 0，说明该会话下任何进程崩溃都不会生成 core 文件。这不是“没找到”，而是根本没开——很多线上服务器默认就是 0。

注意：ulimit -c 只反映当前 shell 的限制，不等于系统全局状态。子进程继承这个值，但其他登录会话、systemd 服务、容器内进程可能各自独立受限。

/proc/sys/kernel/core_pattern 决定 core 文件去哪、叫啥名

运行 cat /proc/sys/kernel/core_pattern 查看内核实际使用的路径模板。常见结果有：

• core：默认行为，写入当前工作目录，文件名固定为 core
• /var/core/core.%e.%p：写入指定目录，按程序名和 PID 命名
• |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h：表示走 systemd-coredump 管道，此时不会落地为普通文件，得用 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 看它实际拿到的 limit。

systemd 系统里 coredumpctl 比找文件更可靠

在现代发行版（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 少踩一半坑。

真正麻烦的不是“怎么开”，而是“开了却找不到”——往往因为路径不对、权限不够、被 systemd 拦截、或者服务跑在容器里没透传 ulimit。先盯住 ulimit -c 和 core_pattern 这两个点，再决定下一步查文件系统还是查 coredumpctl。