Sammlung ätzender Fehlermeldungen (Hadoop und Ganglia)

Diesen Beitrag schrieb ich 16 Jahre und 2 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.

Geschätzte Lesezeit: 2 Minuten

Was folgt ist eine Sammlung wirklich ätzender Fehlermeldungen.

Name node is in safe mode.

$ bin/hadoop dfs -mkdir test
mkdir: org.apache.hadoop.dfs.SafeModeException: Cannot create directory /user/spillerm/test.
Name node is in safe mode.

Zu dieser Meldung kommt es unmittelbar nach dem Start der benötigten Dienste. Weiteres Eingreifen ist hier nicht erforderlich – das Filesystem kommt nach einer Weile selbst aus dem SafeMode hoch und funktioniert dann regulär (im Webinterface ist auch der Hinweis „Safe mode is ON. Safe mode will be turned off automatically.“ zu sehen).

data_thread() got no answer from any [xxx] datasource

Zu dieser Meldung kommt es, wenn der gmetad keinerlei Daten empfängt; das kann entweder daran liegen, dass auf keiner Maschine ein gmond gestartet ist oder aber daran, dass die Clients zwar laufen, die Multicast-Routen aber fehlerhaft sind und somit keine Kommunikation möglich ist.

fsockopen()

Warning: fsockopen() [function.fsockopen]: unable to connect to 127.0.0.1:8652 (Connection refused)
in /var/www/ganglia/ganglia.php on line 304
There was an error collecting ganglia data (127.0.0.1:8652): fsockopen error: Connection refused

Diese Meldung erscheint, wenn man versucht das Ganglia-Webinterface aufzurufen, der gmetad aber gar nicht läuft; ganz klar, dass da dann keine Verbindung aufgebaut werden kann. Prüfen lässt sich das auf der Maschine, auf der der gmetad laufen soll, beispielsweise wie folgt:

$ netstat -nlp | grep 8652

Ist Port 8652 nicht belegt, schafft das Starten des Dienstes Abhilfe. Die Ausgabe von netstat sieht danach in etwa so aus:

$ netstat -nlp | grep 8652
tcp        0      0 0.0.0.0:8652            0.0.0.0:\*               LISTEN     30266/gmetad

not well-formed (invalid token)

/opt/local/sbin/gmetad[18283]: Process XML (testcluster01): XML_ParseBuffer() error at line 53: not well-formed (invalid token)

So schlimm diese Meldung aussieht, so harmlos ist sie eigentlich; in aller Regel hat sie ihren Ursprung durch einen Eintrag in der /etc/ganglia/gmond.conf:

cluster { 
  ... 
  owner = "Bla & Fasel GmbH & Co. KG" 
  ...
}

De facto kann gmond nicht mit dem & umgehen – eine Änderung zu “Bla and Fasel GmbH and Co. KG” schaffte fix Abhilfe ;)

Unable to create tcp_accept_channel.

Beim Starten des gmond kann es hin und wieder zu nachfolgender Fehlermeldung kommen:

$ /opt/local/sbin/gmond --debug=9
loaded module: core_metrics
loaded module: cpu_module
loaded module: disk_module
loaded module: load_module
loaded module: mem_module
loaded module: net_module
loaded module: proc_module
loaded module: sys_module
udp_recv_channel mcast_join=224.0.0.0 mcast_if=NULL port=8649 bind=NULL
tcp_accept_channel bind=NULL port=8649
Unable to create tcp_accept_channel. Exiting.

` Falls das passiert, so ist in erster Linie zu prüfen, ob der genannte Port (8649) durch etwas belegt ist; in aller Regel löst sich das Rätsel insofern, als dass schlicht und ergreifend bereits eine Instanz des gmond läuft:

$ netstat -nlp | grep 8649
tcp        0      0 0.0.0.0:8649                0.0.0.0:\*                   LISTEN      31491/gmond         
udp        0      0 0.0.0.0:8649                0.0.0.0:\*                               31491/gmond
Alle Bilder dieser Seite: © Marianne Spiller – Alle Rechte vorbehalten
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten

Eure Gedanken zu „Sammlung ätzender Fehlermeldungen (Hadoop und Ganglia)“

Ich freue mich über jeden Kommentar, es sei denn, er ist blöd. Deshalb behalte ich mir auch vor, die richtig blöden kurzerhand wieder zu löschen. Die Kommentarfunktion ist über GitHub realisiert, weshalb ihr euch zunächst dort einloggen und „utterances“ bestätigen müsst. Die Kommentare selbst werden im Issue-Tracker und mit dem Label „✨💬✨ comment“ erfasst – jeder Blogartikel ist ein eigenes Issue. Über GitHub könnt ihr eure Kommentare somit jederzeit bearbeiten oder löschen.