Ganglia - gmetad - процесс заканчивается SIGSEGV

Question

Я начал видеть этот вопрос за последние пару дней. Процесс Ganglia gemtad прекращается в течение 5 минут с момента его запуска с SIGSEGV (segfault)

Это было стабильно с последних нескольких месяцев. Не уверен, что изменилось.

Version - gmetad 3.7.1 

Я не вижу никакой дамп или что-нибудь конкретное для gmetad в /вар/Журнал/сообщения или /вар/Журнал/безопасных либо.

система оснастки (сверху) во время этого события

load average: 1.97, 0.99, 0.42 

памяти также выглядит довольно Ok

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

У меня есть процесс superviord что вилы & следит за 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? Цените любые указатели.

Answer 1

Я смог идентифицировать проблему и решить ее.

Некоторые ключевые шаги/выводы -

1. изменить «debug_level» к> 1 в gmetad.conf запустить gmetaa на переднем плане и выплюнуть подробный журнал о том, что его делать.
2. Я узнал, что процесс gmetad был убит в той же точке - когда он пытался обработать файл для определенного узла определенного источника данных.
3. Вы можете прокомментировать весь другой «data_source» из gmetad.conf и попытаться изолировать узел data_source->.
4. После выяснения проблемного узла я просто удалил путь/path/to/rrd/node_dir/file_with_issue или весь каталог. (Необходимо найти лучший способ, так как это потеря данных)
5. Замените debug_level и перезагрузите gmetad!

В моем случае, чтобы точно указать имя файла - «part_max_used.rrd» был имя файла в каталоге/пути/к/ганглиям/RRDS/node_name был первопричина SIGSEGV

Надеется, что это помогает -)