Sammlung ätzender Fehlermeldungen (Hadoop und Ganglia)
Diesen Beitrag schrieb ich 16 Jahre und 1 Monat 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.
- Name node is in safe mode.
- data_thread() got no answer from any [xxx] datasource
- fsockopen()
- not well-formed (invalid token)
- Unable to create tcp_accept_channel.
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
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
