Linux：Fedora 23 Workstation 的 coredump 文件的位置

本文链接：https://blog.csdn.net/imred/article/details/50404031

转载请注明来源：imred的专栏 | http://blog.csdn.net/imred/article/details/50404031
博主使用的Linux发行版是Fedora 23 Workstation桌面版，有时程序运行崩溃了提示core dumped，但是怎么也找不到core文件的位置，今天费了一些工夫，弄明白了这些文件到底存在了哪里。
今天在运行一个程序时，core dump掉了，我想分析一下原因，但是并没有像网上说的那样在本目录下找到core。无奈之下继续百度，发现要产生core文件先要设置一下ulimit。这个ulimit命令是用来限制shell和其他一些进程运行时的可用资源的，它是bash的一个内置命令，其中一个“-c“选项是用来设置core文件的最大大小的（The maximum size of core files created）。我验证了一下我的当前bash环境的设置，果不其然，是0，这也就意味着无法产生core文件了：

[admin@localhost ~]$ ulimit -c
0

通过命令可以设置当前bash环境的限制，将大小限制提高到“unlimited“，字面意思就是无限制了：

[admin@localhost ~]$ ulimit -c unlimited

再检查一下：

[admin@localhost ~]$ ulimit -c
unlimited

这回应该是可以产生core文件了。（这个设置只对当前bash进程有效，打开另一个terminal就无效了）
当我再次运行那个程序，又一次core dumped，但是奇怪的是仍然没有在同目录下找到core文件，确实有些奇怪。
再看看core文件文件名格式的设置文件，/proc/sys/kernel/core_pattern：

[admin@localhost ~]$ cat /proc/sys/kernel/core_pattern 
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %e %P %I

似乎也并不仅仅是一个文件名的格式，里面提到了一个程序名abrt-hook-ccpp，但我当时并没有理会它，而是先找了一下和core dump相关的内容：

[admin@localhost ~]$ man -k coredump
abrt-action-analyze-c (1) - Calculate and save UUID for a problem data direct...
abrt-action-generate-backtrace (1) - Analyzes coredump, generates and saves b...
abrt-action-generate-core-backtrace (1) - Generates coredump-level backtrace
abrt-install-ccpp-hook (1) - Install coredump handler.
coredump.conf (5)    - Coredump storage configuration files
coredump.conf.d (5)  - Coredump storage configuration files
coredumpctl (1)      - Retrieve coredumps from the journal
systemd-coredump (8) - Log and store core dumps

在systemd-coredump的man page中提到了参考信息“core”，然后我就man了一下core，在core的man page里找到了关于/proc/sys/kernel/core_pattern一项很重要的信息，它帮我理解了为什么格式设置文件里会有一个程序名：

Piping core dumps to a program
    Since  kernel  2.6.19,  Linux  supports  an  alternate  syntax  for the /proc/sys/kernel/core_pattern file.  If the  first  character  of  this file  is  a  pipe  symbol (|), then the remainder of the line is interpreted as a program to be executed.  Instead of being written to a disk file,  the  core  dump is given as standard input to the program.  Note the following points:
    ...

原来kernel 2.6.19以后Linux支持了将core文件直接传给一个程序来处理，而不是生成一个磁盘文件。很明显在这里这个程序就是abrt-hook-ccpp。但是它又是什么东西呢？我查了一下它属于哪个rpm包：

[admin@localhost ~]$ rpm -qf /usr/libexec/abrt-hook-ccpp 
abrt-addon-coredump-helper-2.7.0-2.fc23.x86_64

原来它属于一个叫做abrt-addon-coredump-helper的包，从名字上来看，这是abrt程序的一个插件，abrt又是什么呢？继续百度，终于在这里找到了答案：

ABRT 是一个自动化 Bug 检测和报告工具。这是红帽领导开发的一个项目。可通过一个连接器来支持 Java 项目。

好吧，其实这个程序界面我看到过好几次了，它在Fedora 23里是一个叫做Problem Reporting的桌面程序。打开它，我就看到了程序的崩溃信息（次数和我设置了ulimit以后尝试的次数相同）：
这里写图片描述
点击右下角的Details就可以看到具体信息了：

看来abrt对core文件已经进行了一定的分析，但是如果我们不想看它的分析，我们想要自己分析，那从哪里得到原本生成的core文件呢？可以看图片上exploitable分支的最后两个项目：data_directory和coredump，core文件就是$DATA_DIRECTORY/coredump了。
虽然ABRT这个程序方便了系统管理员监控整个系统里程序崩溃的情况，但似乎也造成了一点小小的麻烦，如果对Red Hat系列不熟悉的话可能就会像我一样需要费一点心思了。不过很难说这不是一种未来的趋势，再比如systemd，都想提供一种对系统全局的控制，提供一种大而全的管理方式。
转载请注明来源：imred的专栏 | http://blog.csdn.net/imred/article/details/50404031