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

Core_pattern用于指定核心dumpfile模式名。 如果模式的第一个字符是'|'，内核将进行处理 模式的其余部分作为要运行的命令。核心转储将是 写入该程序的标准输入，而不是写入文件。

您的系统不是将核心转储写入磁盘，而是将其发送到abrt(意思是:自动错误报告工具，而不是“abort”)程序。自动错误报告工具可能没有像它应该被记录的那样…

在任何情况下，快速的答案是您应该能够在/var/cache/abrt中找到您的核心文件，abrt在调用后将它存储在那里。类似地，使用Apport的其他系统可能会在/var/crash中存放内核，等等。

Ulimit -c unlimited使内核文件在“内核转储”后正确地出现在当前目录中。

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

sudo service apport stop

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

一行代码获取最新的核心转储路径:

ls -t $(cat /proc/sys/kernel/core_pattern | awk -F% '{print $1"*"}') 2>/dev/null | head -1

当然，您可以将该行的最后一个-1修改为-4，以获得最后4个核心转储。

注意:如果路径模式在最后一个/之前使用变量，或者当非核心转储文件在该目录下时，这并不预期会起作用。

在最近的Ubuntu(我的例子是12.04)上，可能会打印“分割错误(核心转储)”，但不会在您可能期望的地方生成核心文件(例如本地编译程序)。

如果你的核心文件大小ulimit为0(你没有使用ulimit -c unlimited)就会发生这种情况——这是Ubuntu的默认值。通常情况下，这会抑制“(core dump)”，提示你的错误，但在Ubuntu上，corefiles通过/proc/sys/kernel/core_pattern管道到Apport (Ubuntu的崩溃报告系统)，这似乎导致了误导性的消息。

If Apport discovers that the program in question is not one it should be reporting crashes for (which you can see happening in /var/log/apport.log), it falls back to simulating the default kernel behaviour of putting a core file in the cwd (this is done in the script /usr/share/apport/apport). This includes honouring ulimit, in which case it does nothing. But (I assume) as far as the kernel is concerned, a corefile was generated (and piped to apport), hence the message "Segmentation fault (core dumped)".

最终PEBKAC忘记设置ulimit，但误导性的消息让我认为我疯了一阵子，不知道是什么在吃我的corefiles。

(此外，通常情况下，core(5)手册页——man 5 core——是一个很好的参考，可以了解您的core文件的结束位置以及可能不编写它的原因。)

对于fedora25，我可以在

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

where ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %p % as per ' /proc/sys/kernel/core_pattern'