Ganglia - gmetad - Prozess wird von SIGSEGV beendet

Question

Ich habe dieses Problem in den letzten Tagen zu sehen begonnen. Der Ganglia-Prozess wird innerhalb von 5 Minuten nach dem Start mit SIGSEGV beendet (segfault)

Dies war stabil seit den letzten Monaten..so nicht sicher, was sich geändert hat.

Version - gmetad 3.7.1 

Ich sehe keinen Core-Dump oder etwas Bestimmtes in gmetad /var/log/messages oder /var/log/secure entweder.

System-Snap (von oben) zum Zeitpunkt dieses Ereignisses

load average: 1.97, 0.99, 0.42 

Speicher auch

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

ziemlich Ok sieht Ich habe einen superviord Prozess, Gabeln & die gmetad Uhren -

Hier ist das Überwachungsprotokoll

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 

Hat jemand mit dieser Art von Problem mit gmetad insbesondere konfrontiert? Schätzen Sie alle Zeiger.

Answer 1

Ich war in der Lage, das Problem zu identifizieren und zu lösen.

Einige wichtige Schritte/findings -

1. Ändern Sie den 'debug_level' zu> 1 in gmetad.conf die gmetaa im Vordergrund laufen und ausführliches Protokoll ausspucken, was seine tun.
2. Ich fand heraus, dass gmetad Prozess wurde genau an der gleichen Stelle getötet - wenn es versuchte, eine Datei für einen bestimmten Knoten einer bestimmten Datenquelle zu verarbeiten.
3. Sie könnten alle anderen 'data_source' aus gmetad.conf auskommentieren und versuchen zu isolieren, welcher data_source-> Knoten problematisch ist.
4. Nachdem ich den problematischen Knoten herausgefunden habe, löschte ich einfach/Pfad/to/rrd/node_dir/file_with_issue oder das gesamte Verzeichnis selbst. (Müssen Sie einen besseren Weg finden, da dies Datenverlust ist)
5. Ändern Sie den debug_level zurück und starten Sie das gmetad neu!

In meinem Fall, zeigen Sie einen Dateinamen an Pin - 'part_max_used.rrd' war ein Dateiname unter/path/to/Ganglien/rrds/node_name wurde die Ursache für SIGSEGV

this helps -)