coredump 文件路径配置文件在哪里

在 Linux 系统中，core dump 文件路径的配置文件通常是 /proc/sys/kernel/core_pattern。这个文件指定了在程序崩溃时生成 core dump 文件的路径和文件名格式。

可以使用以下命令来查看当前的配置：

cat /proc/sys/kernel/core_pattern

默认情况下，它的值为 |/usr/share/apport/apport %p %s %c %d %P %E|，意思是当程序崩溃时，会调用 apport 工具来生成 core dump 文件，并将其保存在 /var/crash 目录下。

可以使用以下命令来修改 core dump 文件的路径和文件名格式：

echo "/path/to/core/dumps/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

其中，%e 表示程序的文件名，%p 表示进程 ID，%t 表示时间戳。

需要注意的是，修改 core_pattern 文件的权限需要 root 用户。而且，修改后的配置只在当前会话中生效，重启系统后需要重新设置。如果需要永久生效，可以将修改命令添加到 /etc/sysctl.conf 文件中。

相关问题

coredump文件存放路径

### 查找 CoreDump 文件的默认存放路径

在 Linux 系统中，默认情况下，CoreDump 文件可能不会被保存到特定的位置，而是取决于系统的配置。要确定 CoreDump 文件的具体生成位置，可以通过命令 `cat /proc/sys/kernel/core_pattern` 来查看当前设置的核心转储模式以及文件名模板[^1]。

如果 `/proc/sys/kernel/core_pattern` 的输出是一个简单的字符串（例如 "core"），那么这表示 core 文件将会在同一目录下创建，该目录即为发生崩溃的应用程序的工作目录。然而，当此值指向一个管道或绝对路径时，则意味着核心转储会被重定向至指定的服务进程处理或是直接写入给定路径下的文件中[^4]。

为了确保能够找到所有的 CoreDump 文件，并便于管理和分析，建议手动设定统一的存储位置并给予适当权限：

sudo mkdir -p /data/coredump
echo "/data/coredump/core-%e.%p.%h.%t" | sudo tee /proc/sys/kernel/core_pattern

上述命令会创建一个新的目录用于专门存放 CoreDump 文件，并修改系统参数使得每次产生的 core 文件都按照一定格式命名后放置在此处[^2]。

配置coredump

### 配置 CoreDump 文件生成

为了使应用程序崩溃时能够自动生成核心转储文件（CoreDump），需要调整系统的相应设置。这可以通过多种方式实现。

#### 使用 `ulimit` 命令配置 CoreDump 大小限制
默认情况下，许多Linux发行版设置了不允许创建大型core dump文件的最大尺寸限制。要允许生成这些文件，需修改shell会话中的资源限制：

ulimit -c unlimited

这条指令移除了对单个进程所能产生的最大core file size的约束[^1]。

#### 修改内核参数以控制 CoreDump 行为
更进一步地定制化core dump的行为可通过更改位于 `/proc/sys/kernel/core_pattern` 的特殊文件完成。该路径下的内容决定了当发生致命错误时所采取的动作模式及其输出格式。例如，指定特定目录作为目标存储位置并附加额外信息到文件名中:

echo '/tmp/core-%e.%p' | sudo tee /proc/sys/kernel/core_pattern

上述命令使得所有的core dumps都将被放置于/tmp目录之下，并且其名称将包含执行失败的应用程序的名字(%e)连同PID (%p)[^4]。

对于某些环境而言，可能还需要考虑其他因素如SELinux策略的影响；另外值得注意的是，在多线程或多处理器架构上运行的服务可能会产生多个独立的核心映像文件。

### 调试 CoreDump 文件的方法

一旦成功启用了core dump功能，则可以在应用异常终止之后利用专门设计用于解析此类数据结构的强大工具来进行深入调查。最常用的两种手段分别是GDB (GNU Debugger) 和 objdump 工具集的一部分—后者提供了反汇编等功能支持。

假设有一个名为`myapp`的应用程序已经崩溃并且留下了相应的core dump文件叫做`core.myapp.12345`，那么就可以按照如下方式进行初步诊断：

gdb myapp core.myapp.12345

进入交互界面后，可以尝试打印栈回溯(`bt`)查看调用链路，检查变量状态等操作来定位问题根源[^2]。