我有一个进程在Linux得到一个分割错误。当它失败时,我如何告诉它生成一个核心转储?


当前回答

值得一提的是,如果你建立了一个系统,那么事情就会有点不同。通常情况下,通过core_pattern sysctl值将核心文件通过systemd-coredump(8)进行管道传输。核心文件大小rlimit通常已经配置为“unlimited”。

然后可以使用coredumpctl(1)检索核心转储。

coredump等的存储由coredump.conf(5)配置。在coredumpctl手册页中有一些如何获取核心文件的示例,但简而言之,它看起来像这样:

找到核心文件:

[vps@phoenix]~$ coredumpctl list test_me | tail -1
Sun 2019-01-20 11:17:33 CET   16163  1224  1224  11 present /home/vps/test_me

获取核心文件:

[vps@phoenix]~$ coredumpctl -o test_me.core dump 16163

其他回答

默认情况下,您将得到一个核心文件。检查进程的当前目录是否可写,否则不会创建核心文件。

还有更多的事情可能会影响核心转储的生成。我遇到了这些问题:

转储目录必须是可写的。默认情况下,这是进程的当前目录,但是可以通过设置/proc/sys/kernel/core_pattern来改变。 在某些情况下,/proc/sys/fs/suid_dumpable中的内核值可能会阻止内核的生成。

还有更多的情况可能会阻止手册页中描述的生成- try man核心。

要检查内核转储是在哪里生成的,运行:

sysctl kernel.core_pattern

or:

cat /proc/sys/kernel/core_pattern

其中%e为进程名,%t为系统时间。您可以在/etc/sysctl.conf中修改它,并通过sysctl -p重新加载。

如果没有生成核心文件(通过:sleep 10 &和killall -SIGSEGV sleep进行测试),则通过:ulimit -a检查限制。

如果你的核心文件大小有限,运行:

ulimit -c unlimited

让它无限。

然后再次测试,如果核心转储成功,你会看到“(核心转储)”分割故障指示如下:

分段故障:11(核心转储)

请参见:核心转储-但核心文件不在当前目录?


Ubuntu

在Ubuntu中,核心转储由Apport处理,可以位于/var/crash/。但是,在稳定版本中默认禁用它。

更多细节,请查看:我在哪里找到Ubuntu的核心转储?

操作系统

对于macOS,请参阅:如何在Mac OS X中生成核心转储?

为了激活核心转储,请执行以下操作:

In /etc/profile comment the line: # ulimit -S -c 0 > /dev/null 2>&1 In /etc/security/limits.conf comment out the line: * soft core 0 execute the cmd limit coredumpsize unlimited and check it with cmd limit: # limit coredumpsize unlimited # limit cputime unlimited filesize unlimited datasize unlimited stacksize 10240 kbytes coredumpsize unlimited memoryuse unlimited vmemoryuse unlimited descriptors 1024 memorylocked 32 kbytes maxproc 528383 # to check if the corefile gets written you can kill the relating process with cmd kill -s SEGV <PID> (should not be needed, just in case no core file gets written this can be used as a check): # kill -s SEGV <PID>

一旦corefile被写入,请确保在相关文件(1./2./3.)中再次禁用coredump设置!

如上所述,这里提出的真正问题是如何在未启用核心转储的系统上启用它们。这个问题在这里得到了解答。

如果您希望了解如何为挂起进程生成核心转储,那么答案是

gcore <pid>

如果gcore在您的系统上不可用,那么

kill -ABRT <pid>

不要使用kill -SEGV,因为它经常会调用信号处理程序,使诊断卡住进程更加困难