一、背景

生产环境多次遇到 MySQL 5.7 在线改表时 crash 的情况，crash 产生的 core file 可以用来排查 crash 的原因，但是在 kernel.core_pattern 设置的目录中却没有发现 core file，查看操作系统日志，发现是因为磁盘空间不足导致 core file 写入失败，然而 kernel.core_pattern 设置的目录，其磁盘空间是足够的，这就很奇怪了，为什么会因为磁盘空间不足导致写入失败？

二、问题排查

操作系统版本：redhat 6.3

先看下 linux 系统日志 /var/log/messages：

Aug 26 01:11:47 mydb12 abrt[8716]: Write error: No space left on device
Aug 26 01:11:48 mydb12 abrt[8716]: Error writing '/var/spool/abrt/ccpp-2020-08-26-01:10:20-2711.new/coredump'

系统日志显示写 core file 时，磁盘空间不足，写入路径为

/var/spool/abrt/ccpp-2020-08-26-01:10:20-2711.new/coredump

但是 kernel.core_pattern 配置的并不是这个位置，看下 /etc/sysctl.conf 内核参数配置：
kernel.core_pattern = /cores/core.%e.%t.%p

再使用 sysctl -a | grep kernel.core_pattern 看下当前生效的 kernel.core_pattern 值：
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

为什么 /etc/sysctl.conf 里面配置的内核参数值与实际生效的值不一致？机器安装 MySQL 服务修改内核参数之后，会执行 sysctl -p 来生效，那么是谁后来又修改了这个内核参数值？

通过 abrt 关键词来搜索，最终发现是 abrtd 服务在机器（虚机）重启之后，修改了 kernel.core_pattern 值。

可以通过以下命令查看 abrtd 服务的状态。

[root@mydb12 ~]# service abrtd status
abrtd (pid  2019) is running...

关于 abrtd 服务，它是 RHEL/CentOS 下默认开启 abrtd 进行故障现场记录（包括生成coredump）和故障报告，core文件的生成位置通过 abrt-hook-ccpp 被重定向到了其他位置。

重启 abrtd 服务并不会导致 kernel.core_pattern 被修改，只有重启机器才会修改。

三、结论

redhat 6.3 虚机重启，会导致内核参数 kernel.core_pattern 被 abrtd 服务重置，这个行为可能导致 core file 无法正常生成。

解决方案：

1. 关闭 abrtd 服务，经过测试，abrtd 服务的关闭并不会影响 core file 的生成。
2. 虚机重启后，定时检测 kernel.core_pattern，如果被重置，则通过 sysctl -p 重新生效。

以上结论仅作为参考。