Call From s0/192.168.56.140 to s0:8020 failed on connection exception

ubuntu@s0:~$ hadoop fs -ls /

ls: Call From s0/192.168.56.140 to s0:8020 failed on connection exception: java.net.ConnectException: Connection refused; For more details see:  http://wiki.apache.org/hadoop/ConnectionRefused

开始以为s0的端口没有打开，查了一发现防火墙跟本就没有启用。

后来把所有集群上core-site.xml 配置 hdfs://s0/改成了hdfs://s0:8020/。然后统一重启

再在s0上执行了hadoop namenode -format

再执行hadoop fs -ls /，发现还是报同样的错误。

再执行jsp命令，没有发现 Namenode这个进程。

再执行start-all.sh。Namenode运行了。

最后再执行hadoop fs -ls / 终于可以了。

 

	
		fs.defaultFS
		hdfs://s0:8020/
	

 另外要通过jps命令查看namenode是否已经启动，如果start-all.sh不能启动，那就单独执行hadoop namenode命令。

我执行的时候报错了：

org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: Directory /tmp/hadoop-ubuntu/dfs/name is in an inconsistent state: storage directory does not exist or is not accessible.

 

Directory does not exist？但是为什么刚装完时是存在的呢，抱着试试看的态度，再次执行。

hadoop namenode -format

执行之后再启动，namenode启动成功了，说明上面does not exist的目录在format namenode的时候重新建起来了，但是如果每次重启都要format namenode，也太不靠谱了，不止是麻烦，更大的麻烦是里面的数据不能总被无情的delete掉啊，问题必须解决。

Directory /tmp/hadoop-javoft/dfs/name is in an inconsistent state: storage directory does not exist or is not accessible.这里的目录既然是在tmp下面的，回忆一下，tmp目录下的文件是临时文件会被定期删除的，貌似bug已经露出水面。那就重启计算机试试是不是因为这，重启之前检查一下tmp目录下面确定几个format namenode之后应该有的目录都有的，重启之后，发现全部被删掉。在执行一次 start-dfs.sh，看到tmp目录下面建了一些目录，但是dfs/name目录仍然不存在，在start-dfs.sh时候建了一部分目录和文件。而dfs/name需要在hadoop namenode -format时建立。问题清楚了。

解决方案就很简单，这些目录的位置都是根据hadoop.tmp.dir的位置确定的，所以只需要在conf/core-site.xml覆盖hadoop.tmp.dir的默认值即可：

...
<property>
   <name>hadoop.tmp.dirname>

   <value>/home/ubuntu/Documents/hadoop/hadoop-${user.name}value>

   <description>A base for other temporary directories.description>

property>

...

如此问题解决。。。