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

sudo service apport stop

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

我使用的是Linux Mint 19(基于Ubuntu 18)。我想在当前文件夹中有coredump文件。我必须做两件事:

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

这已经写在答案里了，但我写出来是为了简洁地总结。有趣的是，修改限制不需要root权限(根据https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user，非root只能降低限制，所以这是出乎意料的-欢迎评论)。

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

正如其他人已经指出的那样，程序可能会chdir()。是否允许运行程序的用户写入chdir()指定的目录?如果没有，则不能创建核心转储。 出于某种奇怪的原因，内核转储不命名为core。你可以检查/proc/sys/kernel/core_pattern。此外，您命名的find命令不会找到典型的核心转储。你应该使用find / name "*core "。*”，因为coredump的典型名称是core.$PID

编写在Ubuntu 16.04 LTS下获得核心转储的指令:

As @jtn has mentioned in his answer, Ubuntu delegates the display of crashes to apport, which in turn refuses to write the dump because the program is not an installed package. To remedy the problem, we need to make sure apport writes core dump files for non-package programs as well. To do so, create a file named ~/.config/apport/settings with the following contents: [main] unpackaged=true Now crash your program again, and see your crash files being generated within folder: /var/crash with names like *.1000.crash. Note that these files cannot be read by gdb directly. [Optional] To make the dumps readble by gdb, run the following command: apport-unpack <location_of_report> <target_directory>

引用: Core_dump - Oracle VM VirtualBox

在我的例子中，原因是ulimit命令只影响当前终端。

如果我在第一个终端上设置ulimit -c unlimited。然后我启动一个新的终端来运行程序。当内核转储时，它不会生成内核文件。

您必须确认运行您的程序的终端的核心大小。

以下步骤适用于ubuntu 20.04和ubuntu 21.04:

停止分配服务

sudo service apport stop

设置准备运行程序的终端的核心大小

ulimit -c unlimited

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

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

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

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