未生成核心转储文件

问题描述：

每次我的应用程序崩溃时，都不会生成核心转储文件。我记得几天前，在另一台服务器上生成了它。我在 bash 中使用屏幕运行应用程序，如下所示：

#!/bin/bash
ulimit -c unlimited
while true; do ./server; done

如您所见，ulimit -c unlimited如果我想生成核心转储，我正在使用它，这很重要，但是当我遇到分段错误时，它仍然无法生成核心转储。我该如何让它工作？

解决方案 1：

此链接包含一份关于为何未生成核心转储的良好清单：

• 核心将会比当前的限制更大。

• 您没有转储核心（目录和文件）所需的权限。请注意，核心转储位于转储进程的当前目录中，该目录可能与父进程不同。

• 验证文件系统是否可写入并且具有足够的可用空间。

• 如果工作目录中存在名为 core 的子目录，则不会转储任何核心。

• 如果名为 core 的文件已经存在但具有多个硬链接，则内核将不会转储核心。

• 验证可执行文件的权限，如果可执行文件启用了 suid 或 sgid 位，则默认情况下将禁用核心转储。如果您对文件有执行权限但没有读取权限，情况也是如此。

• 验证该进程未改变工作目录、核心大小限制或可转储标志。

• 某些内核版本无法转储具有共享地址空间的进程（又称线程）。较新的内核版本可以转储此类进程，但会将 pid 附加到文件名中。

• 可执行文件可能采用非标准格式，不支持核心转储。每种可执行文件格式都必须实现核心转储例程。

• 分段错误实际上可能是内核错误，请检查系统日志中是否存在任何错误消息。

• 该应用程序调用了exit()核心转储处理程序而不是使用核心转储处理程序。

解决方案 2：

确保当前目录（崩溃时 -server可能会更改目录）可写。如果服务器调用setuid，则该目录必须可由该用户写入。

另请检查/proc/sys/kernel/core_pattern。这可能会将核心转储重定向到另一个目录，并且该目录必须是可写的。更多信息请见此处。

解决方案 3：

对于systemd系统1，安装包systemd-coredump。 可以通过以下方式找到核心转储：

ls /var/lib/systemd/coredump

此外，这些核心转储被压缩为格式。要解压缩，您可以使用这样的lz4包： 。为了能够使用 调试解压缩的核心转储，我还必须将非常长的文件名重命名为更短的文件名……liblz4-tool`lz4 -d FILE`gdb

1 Debian 9 Stretch

解决方案 4：

查看：

$ sysctl kernel.core_pattern

查看转储是如何创建的（％e 将是进程名称，％t 将是系统时间）。

对于 Ubuntu，转储是由 创建的apport，/var/crash但格式不同（参见内部文件）。

您可以通过以下方式测试：

sleep 10 &
killall -SIGSEGV sleep

如果核心转储成功，您将在分段错误指示后看到“（核心转储）”。

阅读更多：

• 如何在 Ubuntu 中生成核心转储文件

• https://wiki.ubuntu.com/Apport

解决方案 5：

请记住，如果您从服务启动服务器，它将启动不同的 bash 会话，因此 ulimit 在那里无效。尝试将其放入您的脚本中：

ulimit -c unlimited

解决方案 6：

如果你使用的是 Linux 发行版（例如 CentOS、Debian），那么查找核心文件和相关条件的最便捷方式可能是手册页。只需从终端运行以下命令：

man 5 core

解决方案 7：

另外，请检查以确保在/var/core写入核心转储的地方或任何地方都有足够的磁盘空间。如果分区几乎已满或磁盘使用率达到 100%，那么问题就出在这里。我的核心转储平均有几 GB，因此您应该确保分区上至少有 5-10 GB 可用空间。

解决方案 8：

注意：如果您自己编写了任何崩溃处理程序，则可能无法生成核心。因此，请搜索包含以下内容的代码：

signal(SIGSEGV, <handler> );

因此 SIGSEGV 将由处理程序处理，并且您将不会获得核心转储。

解决方案 9：

这里给出的答案很好地涵盖了大多数不创建核心转储的情况。但是，在我的例子中，这些都不适用。我发布这个答案作为对其他答案的补充。

如果您的核心文件因某种原因未创建，我建议您查看 /var/log/messages。其中可能会提示为什么未创建核心文件。在我的情况下，有一行说明了根本原因：

Executable '/path/to/executable' doesn't belong to any package

要解决此问题，请编辑 /etc/abrt/abrt-action-save-package-data.conf 并将 ProcessUnpackaged 从“否”更改为“是”。

ProcessUnpackaged = yes

此设置指定是否为未使用包管理器安装的二进制文件创建核心。

解决方案 10：

如果您调用daemon()然后将进程设为守护进程，则默认情况下当前工作目录将更改为/。因此，如果您的程序是守护进程，那么您应该在目录中寻找核心/，而不是在二进制目录中。

解决方案 11：

虽然这对提问者来说不是问题，因为他们使用 ulimit 命令在脚本中运行了生成核心文件的程序，但我想记录下 ulimit 命令特定于运行它的 shell（如环境变量）。我花了太多时间在一个 shell 中运行 ulimit 和 sysctl 等，在另一个 shell 中运行我想要转储核心的命令，并想知道为什么没有生成核心文件。

我将把它添加到我的 bashrc 中。sysctl 一旦发出，便适用于所有进程，但 ulimit 仅适用于发出它的 shell（可能也适用于后代） - 但不适用于正在运行的其他 shell。

解决方案 12：

以防万一其他人也遇到这个问题。我正在运行其他人的代码 - 确保他们没有处理信号，这样他们就可以正常退出。我注释掉了处理，并得到了核心转储。

解决方案 13：

在centos中，如果你不是root账号来生成core文件：你必须设置该账号具有root权限或者登录root账号：

vim /etc/security/limits.conf

帐户软核 无限
帐户硬核 无限

然后如果你使用 securecrt 或者其他方式登录 shell：

注销 然后重新登录

解决方案 14：

允许从守护进程转储 允许所有由 systemd 启动的守护进程进行核心转储。

编辑：/etc/systemd/system.conf 添加以下内容

DefaultLimitCORE=infinity 编辑：/etc/sysctl.d/core.conf 添加以下内容

kernel.core_pattern = /var/lib/coredumps/core-%e-sig%s-user%u-group%g-pid%p-time%t kernel.core_uses_pid = 1 fs.suid_dumpable = 2

更多详细信息：https ://pve.proxmox.com/wiki/Enable_Core_Dump_systemd

解决方案 15：

当我们的应用程序设置了功能后，它就会停止产生核心转储。

setcap 'cap_sys_nice=eip' /usr/bin/${our_app}

删除它可以重新生成核心转储。

setcap '-r' /usr/bin/${our_app}

另请参阅：如何从 setcap 可执行文件获取核心转储？