答案是配置Linux核心转储需设置ulimit -c和core_pattern。首先通过ulimit -c unlimited设置核心文件大小限制，再配置/proc/sys/kernel/core_pattern定义存储路径与命名规则，如/var/coredumps/core.%e.%p.%t，并确保目录存在且有写权限。排查常见问题包括检查进程的ulimit限制、目录权限、磁盘空间及systemd-coredump干扰。分析时使用gdb加载带调试符号的可执行文件和core文件，定位崩溃原因。
Linux核心转储，或者我们常说的core dump，本质上就是当一个程序意外崩溃时，操作系统会把这个程序当时的内存状态（包括寄存器信息、堆栈、内存映射等）保存到一个文件中。配置它，主要是通过调整
ulimit -c
来控制是否生成以及生成多大的文件，再配合
/proc/sys/kernel/core_pattern
来定义这些文件会存放在哪里，以及它们的名字怎么取。这玩意儿对于我们排查那些只在生产环境复现、难以调试的疑难杂症，简直是救命稻草。
要让Linux在程序崩溃时乖乖地把核心转储文件吐出来，主要得搞定两件事：权限和路径。
首先是权限问题，这由
ulimit -c
来控制。这个命令决定了核心转储文件的大小上限。如果设为0，那程序崩了也不会有core文件。
临时设置： 在当前shell会话中，你可以直接运行
ulimit -c unlimited
（不限制大小）或者
ulimit -c 102400
（限制为100MB）。这种设置只对当前shell及其子进程有效，shell一关，就没了。永久设置： 对于生产环境的服务，我们需要它长期有效。通常是在
/etc/security/limits.conf
文件中添加配置。
# 示例：允许所有用户生成无限大小的core文件* soft core unlimited* hard core unlimited
这里的
soft
是软限制，
hard
是硬限制。一般我们会把两者都设为
unlimited
，或者一个足够大的值。改完这个文件，用户需要重新登录才会生效。对于系统服务，可能需要重启服务甚至整个系统。
接着是核心转储文件的存放路径和命名规则，这由
/proc/sys/kernel/core_pattern
这个内核参数决定。
查看当前设置：
cat /proc/sys/kernel/core_pattern
临时设置：
echo "/var/coredumps/core.%e.%p.%t" > /proc/sys/kernel/core_pattern
这个例子中，core文件会生成在
/var/coredumps/
目录下，文件名会包含：
%e
: 可执行文件名
%p
: 进程ID
%t
: 时间戳其他有用的占位符还有
%u
(UID),
%g
(GID),
%h
(主机名),
%s
(信号编号) 等。永久设置： 修改
/etc/sysctl.conf
文件，添加一行：
kernel.core_pattern = /var/coredumps/core.%e.%p.%t
然后运行
sysctl -p
使配置立即生效。记得，你指定的目录（比如
/var/coredumps/
）必须存在，并且进程要有写入权限。否则，即使
ulimit -c
设对了，core文件也生成不出来。我个人习惯会先
mkdir -p /var/coredumps && chmod 777 /var/coredumps
（或者更严格的权限）来确保万无一失。
百度文心百中
百度大模型语义搜索体验中心
22 查看详情
为什么我的Linux核心转储没有生成？常见原因与排查方法
这绝对是我在实际工作中遇到最多的问题之一。明明感觉一切都配置好了，程序一崩，core文件却不见踪影，那种抓狂的感觉你懂的。这里我总结了一些常见原因和排查思路，希望能帮你少走弯路。
一个很常见的情况是，
ulimit -c
压根就没生效。你可能在某个配置文件里改了，但服务启动时并没有加载到这个配置。你可以用
cat /proc//limits
来查看特定进程的实际
ulimit
设置。如果
Max core file size
是0，那肯定没戏。另一个大头是核心转储文件的路径问题。
/proc/sys/kernel/core_pattern
指向的目录不存在，或者进程没有写入权限，这都是致命的。我经常会忘记创建目录或者给错权限。一个简单的测试方法是，手动创建一个文件看看能不能成功，比如
sudo -u touch /var/coredumps/test_file
。如果不行，那问题就出在这。
还有一些不那么显眼但同样重要的点：
磁盘空间不足： 如果你的分区快满了，系统可能就没法写入巨大的core文件了。这虽然听起来很基础，但真的会发生。程序本身的问题： 有些程序在崩溃时会自己处理信号，或者在退出前执行清理操作，这可能会阻止系统生成core文件。虽然不常见，但值得留意。内核参数
coredump_filter
： 这是一个比较高级的设置，位于
/proc//coredump_filter
。它控制了哪些内存区域会被包含在core文件中。默认情况下，通常是包含所有可写的私有匿名映射和共享内存。如果你或者某个系统工具修改了它，可能会导致core文件内容不完整甚至不生成。
systemd-coredump
： 在一些现代Linux发行版（如CentOS 7+, Ubuntu 16.04+）中，
systemd
接管了核心转储的处理。它会将core文件压缩并存储在
/var/lib/systemd/coredump/
目录下，并且需要用
coredumpctl
命令来查看和提取。如果你发现
core_pattern
被设置成了类似
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
这样的管道命令，那就说明
systemd-coredump
在工作。这时候，传统的
ulimit
和
core_pattern
只是触发机制，实际处理逻辑在
systemd
那边。
为了快速验证配置是否生效，你可以尝试让一个简单的C程序崩溃：
// crash.c#include int main() { int *p = 0; *p = 1; // 尝试写入空指针，导致段错误 return 0;}
编译：
gcc -g crash.c -o crash
运行：
./crash
如果配置正确，你应该能在指定目录找到core文件。
如何分析Linux核心转储文件？常用工具与基本步骤
拿到core文件只是第一步，关键在于如何从中提取有用的信息。这就像医生拿到X光片，得会看才行。在Linux下，
gdb
（GNU Debugger）无疑是分析core文件的瑞士军刀。
分析core文件的基本流程是这样的：
准备好可执行程序和调试符号： 这是最最关键的一步。在编译你的程序时，一定要加上
-g
选项，这样编译器会把调试信息（比如变量名、函数名、行号等）嵌入到可执行文件里。如果没有调试符号，
gdb
也能打开core文件，但你看到的会是汇编代码和内存地址，那分析难度就指数级上升了。
# 编译时加上-ggcc -g my_program.c -o my_program
启动
gdb
并加载core文件：
gdb # 示例：gdb ./my_program /var/cored
以上就是如何在Linux中核心转储 Linux core dump配置的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/430019.html
微信扫一扫 
支付宝扫一扫 
