linux内核参数kernel.core_pattern被abrtd服务重置

一、背景

生产环境多次遇到 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 重新生效。

以上结论仅作为参考。

文章评论

0条评论