我假装已经尝试了所有方法，但我的 Debian 8 在崩溃时不断创建核心转储。这种情况大约一个月发生一两次。它是几个网站的生产服务器，带有打包的 Apache 2.4、php5-fpm 和 mysql。我怀疑是 php5-fpm 崩溃了，因为我在 DocumentRoot 文件夹中获得了转储文件。我获得的文件名为“core”，大小约为 GB。
以下是我已经完成的禁用核心转储的操作，但没有成功：
ln -s /dev/null /etc/systemd/coredump.conf
然后重新启动。没用。
echo '* hard core 0' >> /etc/security/limits.conf
echo "fs.suid_dumpable = 0" >> /etc/sysctl.conf
sysctl -p
然后重新启动。仍然没有成功。我没有将 kernel.suid_dumpable 设置为 0，因为我后来才发现它，但当我找到它时，我还看到它的默认值为零。这些设置无论如何都不会产生任何影响，因为 php5-fpm 不是 setuid。Apache 和 mysql 也是如此，以防不是 php5-fpm 崩溃。
目前有一个脚本可以查找核心转储并将其删除。Crontab 会完成其余工作，但这不是最佳解决方案。
如何全局无条件地禁用 Debian 8 中的核心转储？
答案1
在 Michael Hampton 对 Froggiz 的回答发表评论后，我注意到 Debian 似乎缺少 coredump.conf 手册页，所以我在互联网上搜索并找到了它。该手册页包含许多有用的信息，我想知道为什么 Debian 没有提供它（也许 Debian 没有提供整个 systemd-coredump 东西？）。
但是从该手册页和 systemd-coredump 手册页来看，我获得的核心文件似乎不是来自 systemd，因为 systemd 将它们放在 /var/lib/systemd/coredump 或日志中（具体取决于存储选项），但从不放在崩溃进程的工作目录中。此外，systemd-coredump 手册页（Debian 中也缺少该手册页）指出，要使核心转储功能正常工作，您需要配置 kernel.core_pattern sysctl 参数，使内核真正将核心转储交给 systemd-coredump。
然后我查看了 kernel.core_pattern 的 Debian 值：Debian 默认将该参数设置为“core”，这恰好是我获得的核心转储文件的名称。
我现在假设设置
kernel.core_pattern=|/bin/true
（或者 /bin/false）按照 core(5) 手册页在 sysctl.conf 中将解决问题。
如果我注意到服务器停止创建核心文件，我将在几周后最终接受我的答案。很抱歉，我不能接受迈克尔的评论作为答案，但非常感谢他为我指明了我认为正确的方向。
编辑：我发现这里一种无需等待自发崩溃即可测试配置的方法，我确认这是正确的答案。
答案2
您可以尝试这个： https://wiki.archlinux.org/index.php/Systemd#Disabling_application_crash_dumps_journaling
禁用应用程序崩溃转储日志
/etc/systemd/coredump.conf通过添加以下行来编辑文件：Storage=none并运行：
systemctl daemon-reload重新加载配置。