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

276

在运行C程序时，它显示“（（核心转储）”），但是在当前路径下看不到任何文件。

我已经设置并验证了ulimit：

ulimit -c unlimited 
ulimit -a

我也试图找到一个名为“ core”的文件，但是没有得到core dumped文件？
任何帮助，我的核心文件在哪里？

c  linux  coredump 
— webminal.org
source
1
程序是否在某个时候调用chdir？如果是这样，请看那里。
— 威廉·珀塞尔
2
程序是否更改其工作目录？看这里。
— 理查德·彭宁顿
我会在整个硬盘驱动器中搜索最新文件；）
— Hamish Grubijan 2010年
1
oops no it not there ...我检查了..program chdir到/ mnt，并且/我检查了两个目录，但找不到文件。我什至没有找到/-“ * core”。即使这样也没有显示文件。该程序使用C +源码，同时核心转储它说断言错误== 0首次和错误= 101第二次..插入值
— webminal.org
7
是的，如果您/proc/sys/kernel/core_pattern使用以开头的字符串覆盖，/tmp那么核心转储就将在那里。
— 短暂

Answers:

240

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

[/ proc / sys / kernel /] core_pattern用于指定核心转储文件模式名称。

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

无需将核心转储写入磁盘，而是将系统配置为将其发送到abrt程序。 自动化的错误报告工具可能没有应有的文档记录。

无论如何，快速的答案是您应该能够在中找到核心文件/var/cache/abrt，在abrt调用后将其存储在此处。同样，使用Apport的其他系统可能会松散中的核心/var/crash，依此类推。

— 短暂的
source
30
是的，我编辑了core_pattern，其内容为echo“ core。％e。％p”> / proc / sys / kernel / core_pattern ..现在它在当前目录中创建了核心转储文件。名称为“ core.giis.12344”等。谢谢大家的回答/评论/提示。
— webminal.org 2010年
20
请注意，fedora 18 abrt程序正在存储核心转储，/var/spool/abrt/而不是/var/cache/abrt
— Nelson
4
有没有一种方法可以让用户自己配置，而不是每个人都必须使用系统配置？
— allyourcode 2013年
运行此命令并调用进程时，默认情况下不打开stdout和stderr吗？我看到非常奇怪的事情发生了。当我在我的自定义文件（applog.txt）中使用stderr和stdout的dup2时，我正在写入其他文件（mycore.BIN）的数据被重定向到我用来捕获stdout和stderr（applog.txt）的文件。关于这个有很好的阅读吗？请提出建议。谢谢
— mk..
20
在archlinux商店中的systemd coredumps/var/lib/systemd/coredump/
— Francois
224

在最近的Ubuntu（在我的案例中为12.04）上，可能会打印“段错误（核心已转储）”，但可能没有一个您期望的核心文件生成（例如，本地编译程序）。

如果您的核心文件大小ulimit为0（尚未完成ulimit -c unlimited），则可能会发生这种情况-这是Ubuntu上的默认设置。通常，这会抑制“（核心转储）”，使您误入歧途，但是在Ubuntu上，核心文件通过管道传输到Apport（Ubuntu的崩溃报告系统）/proc/sys/kernel/core_pattern，这似乎会引起误解。

如果Apport发现所讨论的程序不是一个程序，则应该报告崩溃的情况（您可以在中看到情况/var/log/apport.log），它会退回到模拟将内核文件放入cwd中的默认内核行为（这在脚本中完成）/usr/share/apport/apport）。这包括遵守ulimit，在这种情况下，它不执行任何操作。但是（就我而言），就内核而言，生成了一个核心文件（并通过管道进行分配），因此消息为“分段错误（核心已转储）”。

最终PEBKAC忘记设置ulimit，但是这个误导性消息让我觉得我发疯了一段时间，想知道是什么在吞噬我的核心文件。

（此外，通常，core（5）手册页-- man 5 core是核心文件最终存放位置以及可能无法写入的原因的很好参考。）

— t
source
4
非常感谢您-我遇到了同样的问题。顺便说一句，Ubuntu 14.04表现出与您描述的行为完全相同的行为。
— Malte Skoruppa
5
在我的Ubuntu安装（版本14.04修改）上，有一个简单的临时解决方法，可以通过运行sudo service apport stop---在我运行该方法后将其/proc/sys/kernel/core_pattern从apport管道更改为just core。core_pattern我想，Apport足够聪明，可以暂时解决问题。
— 帕特里克·柯林斯
6
“ ulimit -c unlimited”正是我需要的-谢谢！
— Dave C
4
在执行ulimit命令之后，我尝试了所有适用的答案以及此处每个注释中的每个位置，但是仍然无法在我的Ubuntu 16.04 LTS上的任何地方找到核心文件……
— Nagev
2
@ElectricGoat不，我没有。IMO，这是糟糕的UX设计。系统应该只打印路径，或者如果不创建消息，则根本不打印消息。每当或如果有机会进一步调查时，我都会添加自己的答案。
— Nagev
80

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

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

可以通过简单的“ hack”禁用此行为：

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

与往常一样，核心转储的大小必须等于或大于要转储的核心的大小，例如，例如ulimit -c unlimited。

— timss
source
该“ hack”对我不起作用（即使重启后）。我正在运行Arch Linux，并且已经运行了ulimit -c unlimited。
— gsingh2011 2013年
@ gsingh2011可能已过时。我不再运行Arch，因此我无法确定这些天是否可以正常运行。如果您发现问题，请随时用新评论更新我/我们。
— tims
5
@ gsingh2011尝试50-coredump.conf代替coredump.conf。这应该覆盖/lib/sysctl.d/50-coredump.conf。可以使用sysctl -w kernel.core_pattern=core
— Lekensteyn
我不得不关闭appport才能正常运行sudo service apport stop
— rahul003 '18
51

编写说明以在Ubuntu 16.04 LTS下获得核心转储：

  1. 正如@jtn在回答中提到的那样，Ubuntu将崩溃的显示委托给apport，因为该程序不是已安装的程序包，所以转而拒绝编写转储。进行更改之前

  2. 要解决此问题，我们需要确保apport也为非打包程序写入核心转储文件。为此，请创建一个名为〜/ .config / apport / settings的文件，其内容如下：
    [main] unpackaged=true

  3. 现在再次使您的程序崩溃，并查看您的崩溃文件是否在文件夹/ var / crash中生成，其名称为* .1000.crash。请注意，gdb无法直接读取这些文件。进行更改后

  4. [可选]要使gdb使转储可读，请运行以下命令：

    apport-unpack <location_of_report> <target_directory>

参考： Core_dump – Oracle VM VirtualBox

— 安库尔
source
3
这是在Ubuntu 18.04中对我
— 有用
〜/与哪个用户有关？如果进程由root运行，是否意味着/root/.config/apport/settings？
— Nicholi
@Nicholi我相信应该是执行程序的用户。我不确定。
— ankurrc
12

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

  1. 正如其他人已经指出的那样，该程序可能会chdir()。运行该程序的用户是否被允许写入其目录chdir()？如果不是，它将无法创建核心转储。

  2. 由于某些奇怪的原因，核心转储没有命名，core.*您可以检查/proc/sys/kernel/core_pattern一下。另外，您命名的find命令不会找到典型的核心转储。您应该使用find / -name "*core.*"，因为coredump的典型名称是core.$PID

— 阿汉斯
source
这是我的模式-这是否意味着核心文件的名称类似于“ PID.signal.userid”，而不是core.pid？$ cat / proc / sys / kernel / core_pattern / usr / lib / hookCCpp / var / char / abrt％p％s％u
— webminal.org 2010年
9

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

包含 

ProcessUnpackaged = yes

这样就可以为不属于已安装软件包（例如，本地构建的软件包）的二进制文件创建崩溃报告（包括核心转储）。

— MRalwasser
source
6

对于fedora25，我可以在以下位置找到核心文件 

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

其中，ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P %按照'的/ proc / sys目录/内核/ core_pattern”

— 马哈韦德·达拉德
source
5

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

sudo service apport stop

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

— 尼古拉斯·龚
source
3

我使用的是Linux Mint 19（基于Ubuntu 18）。我想coredump在当前文件夹中保存文件。我必须做两件事：

  1. 更改/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)
  2. 将核心文件大小的限制提高 $ ulimit -c unlimited

那已经写在答案中了，但是我写得很简洁。有趣的是，更改限制不需要root特权（根据/ubuntu/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non- root只能降低该限制，因此这是意外的-欢迎对此发表评论）。

— 马里沙
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.