核心已转储，但核心文件不在当前目录下？

Question

核心已转储，但核心文件不在当前目录下？

364

在运行C程序时，它会显示“(core dumped)” ，但我在当前路径下找不到任何文件。

我已经设置并验证了ulimit：

ulimit -c unlimited 
ulimit -a

我还尝试查找名为“core”的文件，但没有得到核心转储文件？
请问哪里可以找到我的核心文件？

- webminal.org

1

程序是否在某个时刻调用了chdir函数？如果是的话，请查看那里。 - William Pursell

2

程序是否更改其工作目录？请查看那里。 - Richard Pennington

1

哎呀，它不在那里...我检查了一下。将程序目录更改为/mnt和/，我检查了这两个目录，但是找不到该文件。我甚至执行了find / -name "*core."，但是仍然没有找到该文件。该程序使用C + sqlite，在插入值时会出现核心转储。第一次它说断言错误==0，第二次则是错误=101。 - webminal.org

9

如果你用以“/tmp”开头的字符串覆盖“/proc/sys/kernel/core_pattern”，那么你的核心转储文件将会被存储在/tmp目录下。 - ephemient

1

相关：[我的问答] AskUbuntu：我在哪里找到核心转储文件，如何在其中查看和分析回溯（堆栈跟踪）？ - Gabriel Staples

显示剩余3条评论

15个回答

271

在最近的Ubuntu系统（我使用的是12.04版本）中，可能会出现“Segmentation fault (core dumped)”的打印信息，但是你可能不会在期望的位置（例如本地编译程序）找到核心文件。

如果你的核心文件大小限制为0（即你没有执行“ulimit -c unlimited”命令），这种情况就会发生——在Ubuntu上默认情况下就是这样。通常这会抑制“(core dumped)”信息，提示你犯了错误，但在Ubuntu上，核心文件通过/proc/sys/kernel/core_pattern管道传输到Apport（Ubuntu的崩溃报告系统），这似乎导致了误导性的消息。

如果Apport发现该程序不是应该报告崩溃的程序之一（你可以在/var/log/apport.log中看到这个过程），它会回退到模拟默认内核行为，将核心文件放置在当前工作目录中（这在脚本/usr/share/apport/apport中完成）。这包括遵守ulimit的规定，在这种情况下它什么也不做。但是（我猜测）就内核而言，已经生成了核心文件（并通过apport管道传输），因此会出现“Segmentation fault (core dumped)”的消息。

最终是PEBKAC（Problem Exists Between Keyboard And Chair，指问题存在于键盘和椅子之间）因为忘记设置ulimit，但误导性的信息让我有一段时间以为自己疯了，想知道是什么在吃我的core文件。

(另外，总的来说，core(5)手册页--man 5 core--是一个很好的参考，可以了解你的core文件存放在哪里以及可能没有被写入的原因。)

- jtn

4

非常感谢您 — 我也遇到了同样的问题。顺便提一下，Ubuntu 14.04的表现与您描述的完全相同。 - Malte Skoruppa

9

在我的Ubuntu安装（修改的14.04版本）中，这个问题有一个简单的临时解决方法，就是运行sudo service apport stop --- 我运行了这个命令后，它把/proc/sys/kernel/core_pattern从apport管道更改为core。我想Apport聪明地暂时修复了core_pattern的设置。 - Patrick Collins

9

"ulimit -c unlimited" 正是我所需要的 - 谢谢！ - Dave C

6

我已经尝试了每一个相关的答案，在执行了ulimit命令后，在这里的每一个评论中搜索了每一个位置，但仍然找不到在我的Ubuntu 16.04 LTS上的任何核心文件... - Nagev

7

@ElectricGoat 我没有。在我看来，这是糟糕的用户体验设计。系统应该只打印路径，或者如果路径未被创建则不打印任何消息。如果我有机会进一步调查，我会添加自己的答案。 - Nagev

显示剩余5条评论

103

随着systemd的推出，还有另一种情况。默认情况下，systemd将在其日志中存储核心转储，并可通过systemd-coredumpctl命令访问。定义在core_pattern文件中：

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

最简单的检查存储的核心转储方式是通过coredumpctl list命令（旧的核心转储可能已被自动删除）。可以通过一种简单的“hack”禁用此行为：

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

一如既往，核心转储的大小必须等于或大于正在转储的核心的大小，例如通过 ulimit -c unlimited 执行。

- timss

那个“hack”对我没用（即使重启后）。我正在运行Arch Linux，并且已经运行了ulimit -c unlimited。 - gsgx

@gsingh2011 这可能已经过时了。我不再使用 Arch 了，所以我不能说它是否应该在这些天里工作。如果您能弄清楚，请随时用一条新评论更新我/我们。 - timss

6

请尝试使用50-coredump.conf替代coredump.conf。这样可以覆盖/lib/sysctl.d/50-coredump.conf。要恢复默认设置，请使用sysctl -w kernel.core_pattern=core命令。 - Lekensteyn

我必须关闭Appport才能使其工作。 sudo service apport stop - rahul003

在Ubuntu 21.10上，我必须先安装systemd-coredump，然后才能让coredumpctl命令正常工作。之后就很容易了 ;) - oligofren

94

在 Ubuntu 16.04 LTS 下编写获取核心转储的指令：

如 @jtn 在他的回答中提到的那样，Ubuntu 将崩溃显示委托给 apport，后者拒绝写入转储文件，因为该程序不是已安装软件包。
要解决此问题，我们需要确保 apport 也为 非软件包 程序编写核心转储文件。为此，请创建一个名为~/.config/apport/settings 的文件，并填入以下内容：
[main] unpackaged=true
现在再次崩溃您的程序，看看生成的崩溃文件是否位于文件夹 /var/crash 中，名称类似于 *.1000.crash。请注意，这些文件不能直接由 gdb 读取。
[可选] 要使转储文件可被 gdb 读取，请运行以下命令：

apport-unpack <location_of_report> <target_directory>

参考文献： Core_dump – Oracle VM VirtualBox

- ankurrc

7

在Ubuntu 18.04中，这是我唯一行之有效的解决方案。 - greuze

“~/” 指的是哪个用户？如果进程由 root 运行，那么 /root/.config/apport/settings 是什么意思？ - Nicholi

@Nicholi 我认为应该是执行程序的用户。不过我不太确定。 - ankurrc

截至 Ubuntu 21.04，此方法仍然可行。 - John Freeman

适用于Ubuntu 20.04.4。 - Not Saying

13

我可以想到以下两种可能性：

正如其他人已经指出的，程序可能会调用chdir()函数。运行该程序的用户是否被允许写入它所切换到的目录？如果不行，那么就无法创建核心转储。
由于某些奇怪的原因，核心转储文件没有命名为core.*。您可以通过检查/proc/sys/kernel/core_pattern来确认这一点。此外，您所提到的 find 命令将无法找到典型的核心转储文件。您应该使用 find / -name "*core.*"，因为典型的核心转储文件名为core.$PID。

- ahans

这是我的模式 - 这是否意味着核心文件命名为“PID.signal.userid”而不是“core.pid”？ $cat /proc/sys/kernel/core_pattern /usr/lib/hookCCpp /var/char/abrt %p %s %u - webminal.org

1

如果虚拟文件 /proc/sys/kernel/core_pattern 的内容以管道符号 | 开头，则该文件将不会被写入由 core_pattern 定义的文件，而是启动在管道符号后定义的命令，并将核心文件写入该程序的 stdin。之后，完全由程序处理核心文件内容。 - Mikko Rantalainen

关于第一项：不，程序不会核心转储；它会看到一个“EPERM”。只有当程序无法正确处理错误时，它才可能被迫终止（以防止更多的无聊事情发生）。 - U. Windl

11

在Ubuntu18.04中，获取核心文件最简单的方法是输入以下命令以停止apport服务。

sudo service apport stop

然后重新运行应用程序，你将在当前目录中获得转储文件。

- Nicolas Gong

我尝试了这个，得到了/etc/init.d/apport: 68: /etc/init.d/apport: cannot create /proc/sys/fs/suid_dumpable: Operation not permitted的错误信息，仍然找不到崩溃文件。我已经设置了ulimit -c unlimited。有人提到了/proc/sys/kernel/core_pattern，但我甚至看不到这个文件。还需要做什么？ - doraemon

抱歉，由于我没有遇到这个问题，无法为您提供好的答案。不过，我认为您可以学习一下 apport 服务的知识，这样就可以知道核心转储文件在哪里了。这是 apport 的文档链接：https://wiki.ubuntu.com/Apport。 - Nicolas Gong

10

我在我的Ubuntu 20.04系统中找到了核心文件的位置：

/var/lib/apport/coredump

- Hwanyong Lee

9

如果在 RHEL 上使用 abrt 时，二进制文件缺少核心转储，请确保 /etc/abrt/abrt-action-save-package-data.conf 文件存在。

ProcessUnpackaged = yes

这使得可以为未安装的软件包中的二进制文件（例如本地构建的文件）创建崩溃报告（包括核心转储）。

- MRalwasser

你忽略了一个事实，当输出“(core dumped)”时，表示已经转储了核心；如果没有转储核心，则不会看到该消息。 - U. Windl

8

针对 Fedora25，我可以在以下位置找到核心文件：

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

根据 /proc/sys/kernel/core_pattern，ccpp-2017-02-16-16:36:51-2974"是模式"%s %c %p %u %g %t %P %"

- mahaveer darade

6

我正在使用Linux Mint 19 (基于Ubuntu 18)，我希望在当前文件夹中有coredump文件。我需要做两件事：

更改 /proc/sys/kernel/core_pattern 的值(通过# echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern 或者 # sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
通过$ ulimit -c unlimited提高核心文件大小的限制

这已经在回答中写过了，但我想简洁地总结一下。有趣的是，更改限制并不需要root权限（根据https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user，非root用户只能降低限制，所以这是意外的 - 关于这个问题的评论是受欢迎的）。

- Marisha

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- ephemient · Accepted Answer

阅读/usr/src/linux/Documentation/sysctl/kernel.txt。

core_pattern用于指定核心转储文件的模式名称。

如果模式的第一个字符是“|”，则内核将把模式的其余部分视为要运行的命令。核心转储将被写入该程序的标准输入而不是文件中。

你的系统已配置成将核心转储发送到abrt（意思是：自动漏洞报告工具，而不是“abort”）程序，而不是将其写入磁盘。自动漏洞报告工具可能没有如文档化那样详细说明。...

无论如何，简单的答案是，你应该能够在/var/cache/abrt找到核心文件，abrt在被调用后会将其存储在那里。同样，使用Apport的其他系统可能会将核心文件存储在/var/crash等位置。