当我执行要处理的程序时，它失败并显示以下消息：
...
Aborted (core dumped)
但是，没有创建核心转储。核心转储是先前编写的，我不记得我更改了与此相关的任何内容。
跑步的时候ulimit -a我回来了
$ ulimit -a
core file size (blocks, -c) unlimited
...
其他要点
/proc/sys/fs/suid_dumpable。当前，在我的机器上将其设置为0。我尝试将其更改为1或2，但没有区别。不幸的是，我不记得何时可以完成上一次成功的核心转储。
Answers:
要禁用供应商提供的配置文件，建议的方法是将符号链接放置到
/dev/null中的配置目录中/etc/，并与供应商配置文件使用相同的文件名。
sudo ln -s /dev/null /etc/sysctl.d/coredump.conf
sudo systemd-sysctl
自从systemd以来，事物的管理方式有所不同。
systemd的systemd-sysctl.service只是运行sysctl在启动的合适时间点，和手柄的手重新运行它的变化。而且，在不调查配置文件的用途和内容之前，不要创建/覆盖配置文件。
50-coredump.conf，为了在当前引导中应用设置，我不得不手动运行更改sysctl设置，请参见stackoverflow.com/q/2065912/427545。
sysctl -w kernel.core_pattern="core"
您可能想使用该coredumpctl命令检索核心转储或在其上运行gdb。那是与他们打交道的“经系统批准的”方法。：-/
从某种意义上说，systemd捕获所有这些东西是一件好事，因为它会在一段时间后自动擦除它们，并且还可以轻松地上传故障转储以进行错误报告。
但是，对于那些在systemd介入之前知道coredumps如何工作的人来说，这是一个令人震惊的变化，几乎没有通知或暗示的方式。即使删除名为“ core.pid.txt”的文件，并附带使用coredumpctl的说明来获取您的coredump以及如何关闭.txt文件的创建，这也将是一个很大的帮助，即使这些文件也会文件系统一段时间。
sudo systemd-coredumpctl显示所有缺少的核心转储。您的解决方案有效，但仅在系统重新启动后才有效。