答案是配置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
ulimit -c unlimited
ulimit -c 102400
/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
/var/coredumps/
%e
%p
%t
%u
%g
%h
%s
/etc/sysctl.conf
kernel.core_pattern = /var/coredumps/core.%e.%p.%t
然后运行
sysctl -p
/var/coredumps/
ulimit -c
mkdir -p /var/coredumps && chmod 777 /var/coredumps
这绝对是我在实际工作中遇到最多的问题之一。明明感觉一切都配置好了,程序一崩,core文件却不见踪影,那种抓狂的感觉你懂的。这里我总结了一些常见原因和排查思路,希望能帮你少走弯路。
一个很常见的情况是,
ulimit -c
cat /proc/<PID>/limits
ulimit
Max core file size
/proc/sys/kernel/core_pattern
sudo -u <运行程序的用户> touch /var/coredumps/test_file
还有一些不那么显眼但同样重要的点:
coredump_filter
/proc/<PID>/coredump_filter
systemd-coredump
systemd
/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 <stdio.h>
int main() {
int *p = 0;
*p = 1; // 尝试写入空指针,导致段错误
return 0;
}编译:
gcc -g crash.c -o crash
./crash
拿到core文件只是第一步,关键在于如何从中提取有用的信息。这就像医生拿到X光片,得会看才行。在Linux下,
gdb
分析core文件的基本流程是这样的:
-g
gdb
# 编译时加上-g gcc -g my_program.c -o my_program
gdb
gdb <你的可执行程序> <core文件路径> # 示例:gdb ./my_program /var/cored
以上就是如何在Linux中核心转储 Linux core dump配置的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号