假设一个（非常）大的进程崩溃并转储核心，并且我们从其他信息（可能是断言消息，也可能是其他信息）中知道原因。
有没有办法阻止核心转储完全生成，因为在这种情况下这是一种浪费？
例如，核心转储进程的 kill -9 是否会中断核心文件的生成？
显然，如果我们提前知道我们不想要核心转储，我们可以适当地设置 ulimit 或使用操作系统的各种核心文件控制实用程序。
但是这个问题是关于“核心转储已在进行中”阶段的......
（例如，假设我是 https://stackoverflow.com/questions/18368242/how-to-bypass-a-2tb-core-dump-file-system-limit 并且不想浪费 5-6 TB 的磁盘空间 :) )
答案1
一般来说：不，没有办法可靠地终止核心转储。
话虽如此，但商业 *NIX 仍有可能（至少在 Linux 中），但可能没有办法
可能性在于 3.x 系列的内核可以中断文件写入。一种可能性是找到执行转储的线程并反复向其发送 SIGKILL，直到成功。
这贴片系列在某种程度上解决了该问题。
另一种可能性是使用 coredump_pattern 的替代语法。手册说，自 2.6.19 以来，您可以使用管道和程序（带参数）来处理转储，而不是模式。因此，您将可以控制将哪个转储写入哪里（/dev/null 显然是您无用核心的候选对象）。
此补丁还值得关注：http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-06/msg00918.html
答案2
答案3
“如果内核在核心文件生成期间检测到信号接收，它会立即停止该过程。因此，就会出现核心文件被截断的情况。”
根据这个systemd 网页kill -9 就可以了。
另外在生产环境中，我的一个同事确实成功地杀死了 -9 PID 并中断了核心转储的生成，只是要注意服务器已经安装了 abrt，所以这可能是 abrt 的问题。
答案4
看起来您可以运行 ulimit -c（假设您正在使用 bash）来限制核心转储大小。
看：https://askubuntu.com/questions/220905/how-to-remove-limit-on-core-dump-file-size
和