定制core dump 文件的文件名

本文介绍如何在Linux系统中定制coredump文件的名称及路径。通过修改内核参数,可以为core文件添加更多元的信息,如程序名和进程ID,便于故障排查。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Linux使用笔记: 定制core dump文件的文件名

在开发过程中,当一个Linux程序异常退出时,我们可以通过core文件来分析它异常的详细原因。缺省情况下,Linux在程序异常时不产生core文件,要想让程序异常退出时产生core dump文件,需要使用ulimit命令更改coredump的设置:

ulimit -c unlimited 

上面的命令表示在程序异常时产生core dump文件,并且不对core dump文件的大小进行限制。

上述设置只是使能了core dump功能,缺省情况下,内核在coredump时所产生的core文件放在与该程序相同的目录中,并且文件名固定为core。很显然,如果有多个程序产生core文件,或者同一个程序多次崩溃,就会重复覆盖同一个core文件。

我们通过修改kernel的参数,可以指定内核所生成的coredump文件的文件名。例如,Easwy使用下面的命令使kernel生成名字为core.filename.pid格式的core dump文件:

echo 'core.%e.%p' > /proc/sys/kernel/core_pattern 

这样配置后,产生的core文件中将带有崩溃的程序名、以及它的进程ID。上面的%e%p会被替换成程序文件名以及进程ID。

可以在core_pattern模板中使用变量还很多,见下面的列表:

  • %% 单个%字符
  • %p 所dump进程的进程ID
  • %u 所dump进程的实际用户ID
  • %g 所dump进程的实际组ID
  • %s 导致本次core dump的信号
  • %t core dump的时间 (由1970年1月1日计起的秒数)
  • %h 主机名
  • %e 程序文件名

如果在上述文件名中包含目录分隔符”/“,那么所生成的core文件将会被放到指定的目录中。

需要说明的是,在内核中还有一个与coredump相关的设置,就是/proc/sys/kernel/core_uses_pid。如果这个文件的内容被配置成1,那么即使core_pattern中没有设置%p,最后生成的core dump文件名仍会加上进程ID。

对所生成的core dump进程分析,需要使用调试工具,例如GDB等。可以参见Easwy的其它文章。

原创文章,请阅读页脚的许可方式,转载请注明:转载自易水博客 [http://easwy.com/blog/ ]

本文链接地址: http://easwy.com/blog/archives/customize-filename-of-core-dump/

root权限不能vim编辑,echo进去,

/proc文件系统的内容是kernel映射出来的内存内容,并不在真实文件系统上


### 如何生成和分析 Core Dump 文件 #### 配置 `ulimit` 以启用 Core Dump 文件生成Linux 系统中,默认情况下可能未启用核心转储功能。为了允许生成 Core Dump 文件,可以通过调整 `ulimit` 参数实现。具体操作如下: 运行以下命令以查看当前系统的 Core Dump 大小限制: ```bash ulimit -c ``` 如果返回值为 `0`,则表示禁用了 Core Dump 功能。要启用该功能,需设置其大小无限制(或其他适当值)。例如: ```bash ulimit -c unlimited ``` 这一步骤确保当程序崩溃时能够生成完整的 Core Dump 文件[^1]。 #### 设置 Core Pattern 定义文件路径 Core Dump 的存储位置及其命方式由 `/proc/sys/kernel/core_pattern` 控制。编辑此配置项可以让系统自定义 Core Dump 文件的位置与称格式。常见的占位符包括 `%e` 表示可执行文件名、`%p` 进程 ID 和其他选项如时间戳 `%t` 等[^4]。 修改方法如下所示: ```bash echo "/tmp/core-%e.%p" | sudo tee /proc/sys/kernel/core_pattern ``` 上述例子会将所有的 Core Dumps 存放在临时目录下,并附加应用程序的字及 PID 来区分不同实例产生的数据[^3]。 #### 使用 GDB 调试 Core Dump 文件 一旦捕获到了一个有效的 Core Dump 文件之后,就可以利用 GNU Debugger (GDB) 对其展开深入研究了。基本流程涉及加载目标二进制镜像连同对应的 Core 数据一起载入调试器环境之中。 启动 GDB 并指定需要审查的目标应用以及关联的核心记录作为输入参数之一即可开始工作流: ```bash gdb ./application_binary_path core_dump_file_name ``` 进入交互界面后尝试一些基础指令来探索现场状态,比如打印栈回溯信息(`bt`)或者检查特定变量的内容等等[^2]: ```plaintext (gdb) bt full # 显示整个调用堆栈详情 (gdb) frame N # 切换至第N层帧上下文中 (gdb) print var # 输出某个局部或全局量var的具体数值表现形式 ``` 通过以上步骤便能有效地定位问题所在并采取相应措施加以修正。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值