如何在Linux中核心转储 Linux core dump配置

P粉602998670

发布时间：2025-09-08 10:22:02

923人浏览过

来源于php中文网

原创

答案是配置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中核心转储 linux core dump配置

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
```
（或者更严格的权限）来确保万无一失。

AdsGo AI
全自动 AI 广告专家，助您在数分钟内完成广告搭建、优化及扩量

下载

为什么我的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文件，但你看到的会是汇编代码和内存地址，那分析难度就指数级上升了。
```
# 编译时加上-g
gcc -g my_program.c -o my_program
```

启动
gdb
并加载core文件：

gdb <你的可执行程序> 
# 示例：gdb ./my_program /var/cored

Linux网络调优项目教程_TCPIP参数优化与带宽管理

Linux主机网络配置实战_地址与网关设置解析【指导】

Linux系统信息快速获取_主机状态查看方法【技巧】

Linux系统运行日志理解_问题定位思路解析【指导】

Linux服务器高可用项目教程_PacemakerCorosyncHA实践