0

最近几天我开始看到这个问题。Ganglia gemtad 进程在 SIGSEGV 启动后 5 分钟内终止（segfault）

自过去几个月以来，这一直很稳定。所以不确定发生了什么变化。

Version - gmetad 3.7.1

我在/var/log/messages或/var/log/secure 中也没有看到任何核心转储或任何特定于 gmetad 的内容。

此事件发生时的系统快照（从顶部开始）

load average: 1.97, 0.99, 0.42

内存看起来还不错

 free -m
             total       used       free     shared    buffers     cached
Mem:          7989       3624       4364          0        333       2562
-/+ buffers/cache:        728       7260
Swap:         4095          0       4095

我有一个分叉和监视 gmetad 的超级进程 -

这是主管日志

2016-10-20 14:34:55,707 INFO exited: gmetad (terminated by SIGSEGV; not expected)
2016-10-20 14:34:55,707 INFO received SIGCLD indicating a child quit
2016-10-20 14:34:57,712 INFO spawned: 'gmetad' with pid 24561
2016-10-20 14:34:59,929 INFO exited: gmetad (terminated by SIGSEGV; not expected)
2016-10-20 14:34:59,929 INFO received SIGCLD indicating a child quit
2016-10-20 14:35:02,932 INFO spawned: 'gmetad' with pid 24593
2016-10-20 14:35:04,897 INFO exited: gmetad (terminated by SIGSEGV; not expected)
2016-10-20 14:35:04,897 INFO received SIGCLD indicating a child quit
2016-10-20 14:35:08,903 INFO spawned: 'gmetad' with pid 24618
2016-10-20 14:35:11,257 INFO exited: gmetad (terminated by SIGSEGV; not expected)
2016-10-20 14:35:11,257 INFO received SIGCLD indicating a child quit
2016-10-20 14:35:12,257 INFO gave up: gmetad entered FATAL state, too many start retries too quickly

有没有人特别遇到过 gmetad 的这种问题？感谢任何指针。

4

1 回答 1

0

我能够识别问题并解决。

一些关键步骤/发现 -

  1. 将 gmetad.conf 中的 'debug_level' 更改为 > 1 以在前台运行 gmetaa 并吐出详细的日志记录它在做什么。
  2. 我发现 gmetad 进程在完全相同的点被杀死 - 当它试图处理特定数据源的特定节点的文件时。
  3. 您可以从 gmetad.conf 中注释掉所有其他“data_source”，并尝试找出哪个 data_source->node 有问题。
  4. 在找出有问题的节点之后，我只是删除了 /path/to/rrd/node_dir/file_with_issue 或整个目录本身。（需要找到更好的方法，因为这是数据丢失）
  5. 改回 debug_level 并重新启动 gmetad！

就我而言，要确定文件名 - 'part_max_used.rrd' 是 /path/to/ganglia/rrds/node_name 下的文件名是 SIGSEGV 的根本原因

希望这可以帮助 -）

于 2016-10-20T21:14:57.930 回答