我假装我已经尝试了所有东西，但是当发生崩溃时，我的Debian 8不断创build核心转储。 一个月内发生一次或两次。 它是几个网站的生产服务器，包装Apache 2.4，php5-fpm和mysql。 我怀疑这是php5-fpm崩溃，因为我得到了DocumentRoot文件夹中的转储文件。 我得到的文件名为“核心”，它的大小在千兆字节左右。
这里是我已经做了禁用核心转储，没有成功：
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，但这不是最好的解决scheme。
我如何全局无条件地禁用Debian 8中的核心转储？
你可以试试这个： https ： //wiki.archlinux.org/index.php/Systemd#Disabling_application_crash_dumps_journaling
禁用应用程序崩溃转储日志logging通过添加以下行来编辑文件
/etc/systemd/coredump.confStorage=none并运行：
systemctl daemon-reload重新加载configuration。
在迈克尔·汉普顿对Froggiz的回复发表评论之后，我注意到Debian似乎缺less一个coredump.conf的联机手册，所以我在网上找了它并find它。 那个manpage包含了很多有用的信息，我想知道为什么Debian在没有它的情况下运行（也许Debian没有运行整个systemd-coredump的东西？）。
但是，从该man页面和systemd-coredump联机帮助页看来，我得到的核心文件不是来自systemd，因为systemd根据Storage选项将它们放在/ var / lib / systemd / coredump或日志中，但从不崩溃进程的工作目录。 此外，systemd-coredump联机帮助页（在Debian中也丢失了）说，要使核心转储function正常工作，需要configurationkernel.core_pattern sysctl参数，以使内核实际将核心转储交给systemd-coredump。
然后，我查看了kernel.core_pattern的Debian值：默认情况下，Debian将该参数设置为“core”，这正好是我所获得的核心转储文件的名称。
我现在假设这个设置
kernel.core_pattern=|/bin/true
（或/ bin / false）在sysctl.conf根据核心（5）手册页将解决问题。
如果我注意到服务器停止创build核心文件，我将在几周内接受我的答案。 对不起，我不能接受迈克尔的评论作为回答，但非常感谢他指出我相信是正确的方向。
编辑：我已经find了一种方法来testingconfiguration，而不必等待一个自发的崩溃，我确认这是正确的答案。