Return-Path: X-Original-To: apmail-hadoop-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 02C3210EFA for ; Thu, 12 Sep 2013 01:42:18 +0000 (UTC) Received: (qmail 64903 invoked by uid 500); 12 Sep 2013 01:42:13 -0000 Delivered-To: apmail-hadoop-user-archive@hadoop.apache.org Received: (qmail 64798 invoked by uid 500); 12 Sep 2013 01:42:13 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 64791 invoked by uid 99); 12 Sep 2013 01:42:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Sep 2013 01:42:12 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cipher.chen2012@gmail.com designates 209.85.215.44 as permitted sender) Received: from [209.85.215.44] (HELO mail-la0-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Sep 2013 01:42:09 +0000 Received: by mail-la0-f44.google.com with SMTP id eo20so8111427lab.17 for ; Wed, 11 Sep 2013 18:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AY65NFpRu0VYp8RLbbFhraWFs6ZL3ZvCJEObfITYpsM=; b=iuVcaoLJFsIpiN/nGkG2bg7D5qdiOuH7FzE/TduN2hg7AHGSrVqA3BQZEUfMivRojf z41m//oIlJ2qpPe0h6zc4uusW0I0BiQqzeX+fTepIYyrRwHG3IDHZa1Xq3FaQrdBBnRj gxsak96KXWM5V2kO9YSSOhBUMYx6G8gi5avltWXuY5baPaTaE3U3NrlgUsKCv6DRsTCS uPHU11f6Q3PDKSLbRas154SgBuBFLfLnPrSDfl/b+600ZxadGPB3I8opz57dT3PhLKr0 EeO+ovhwgrYBTkkUg6oYJl+xvfj96AdrpDSvfmw7iFArLS9OoHE6e0yjHeFTPJsP34ML gAAA== MIME-Version: 1.0 X-Received: by 10.152.3.201 with SMTP id e9mr3921437lae.24.1378950107379; Wed, 11 Sep 2013 18:41:47 -0700 (PDT) Received: by 10.112.190.40 with HTTP; Wed, 11 Sep 2013 18:41:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Sep 2013 09:41:47 +0800 Message-ID: Subject: Re: hadoop cares about /etc/hosts ? From: Cipher Chen To: user@hadoop.apache.org Content-Type: multipart/alternative; boundary=089e013d14ca503ff704e625d70b X-Virus-Checked: Checked by ClamAV on apache.org --089e013d14ca503ff704e625d70b Content-Type: text/plain; charset=UTF-8 Hi, all Thanks for all your replies and guidance. Although I haven't figured out why. :) On Wed, Sep 11, 2013 at 4:03 PM, Jitendra Yadav wrote: > Hi, > > So what you were expecting while pinging master? > > As per my understanding it is working fine.Well there is no sense of using > localhost and hostname on same ip, for localhost it's always preferred to > use loopback method i.e 127.0.0.1 > > Hope this will help you. > > Regards > Jitendra > On Wed, Sep 11, 2013 at 7:05 AM, Cipher Chen wrote: > >> So >> for the first *wrong* /etc/hosts file, the sequence would be : >> find hdfs://master:54310 >> find master -> 192.168.6.10 (*but it already got ip here*) >> find 192.168.6.10 -> localhost >> find localhost -> 127.0.0.1 >> >> >> The other thing, when 'ping master', i would got reply from >> '192.168.6.10' instead of 127.0.0.1. >> So it's not simply the Name Resolution on the os level. Or i'm totally >> wrong? >> >> >> >> On Tue, Sep 10, 2013 at 11:13 PM, Vinayakumar B < >> vinay.opensource@gmail.com> wrote: >> >>> Ensure that for each ip there is only one hostname configured in >>> /etc/hosts file. >>> >>> If you configure multiple different hostnames for same ip then os will >>> chose first one when finding hostname using ip. Similarly for ip using >>> hostname. >>> >>> Regards, >>> Vinayakumar B >>> On Sep 10, 2013 9:27 AM, "Chris Embree" wrote: >>> >>>> This sound entirely like an OS Level problem and is slightly outside of >>>> the scope of this list, however. I'd suggest you look at your >>>> /etc/nsswitch.conf file and ensure that the hosts: line says >>>> hosts: files dns >>>> >>>> This will ensure that names are resolved first by /etc/hosts, then by >>>> DNS. >>>> >>>> Please also ensure that all of your systems have the same configuration >>>> and that your NN, JT, SNN, etc. are all using the correct/same hostname. >>>> >>>> This is basic Name Resolution, please do not confuse this with a Hadoop >>>> issue. IMHO >>>> >>>> >>>> On Mon, Sep 9, 2013 at 10:05 PM, Cipher Chen >>> > wrote: >>>> >>>>> Sorry i didn't express it well. >>>>> >>>>> conf/masters: >>>>> master >>>>> >>>>> conf/slaves: >>>>> master >>>>> slave >>>>> >>>>> The /etc/hosts file which caused the problem (start-dfs.sh failed): >>>>> 127.0.0.1 localhost >>>>> 192.168.6.10 localhost >>>>> ### >>>>> >>>>> 192.168.6.10 tulip master >>>>> 192.168.6.5 violet slave >>>>> >>>>> But when I commented the line appended with hash, >>>>> 127.0.0.1 localhost >>>>> # >>>>> 192.168.6.10 localhost >>>>> ### >>>>> >>>>> 192.168.6.10 tulip master >>>>> 192.168.6.5 violet slave >>>>> >>>>> The namenode starts successfully. >>>>> I can't figure out *why*. >>>>> How does hadoop decide which host/hostname/ip to be the namenode? >>>>> >>>>> BTW: How could namenode care about conf/masters and conf/slaves, >>>>> since it's the host who run start-dfs.sh would be the namenode. >>>>> Namenode doesn't need to check those confs. >>>>> Nodes listed in conf/masteres would be SecondaryNameNode, isn't it? >>>>> I >>>>> >>>>> >>>>> On Mon, Sep 9, 2013 at 10:39 PM, Jitendra Yadav < >>>>> jeetuyadav200890@gmail.com> wrote: >>>>> >>>>>> Means your $HADOOP_HOME/conf/masters file content. >>>>>> >>>>>> >>>>>> On Mon, Sep 9, 2013 at 7:52 PM, Jay Vyas wrote: >>>>>> >>>>>>> Jitendra: When you say " check your masters file content" what are >>>>>>> you referring to? >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 9, 2013 at 8:31 AM, Jitendra Yadav < >>>>>>> jeetuyadav200890@gmail.com> wrote: >>>>>>> >>>>>>>> Also can you please check your masters file content in hadoop conf >>>>>>>> directory? >>>>>>>> >>>>>>>> Regards >>>>>>>> JItendra >>>>>>>> >>>>>>>> On Mon, Sep 9, 2013 at 5:11 PM, Olivier Renault < >>>>>>>> orenault@hortonworks.com> wrote: >>>>>>>> >>>>>>>>> Could you confirm that you put the hash in front of >>>>>>>>> 192.168.6.10 localhost >>>>>>>>> >>>>>>>>> It should look like >>>>>>>>> >>>>>>>>> # 192.168.6.10 localhost >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Olivier >>>>>>>>> On 9 Sep 2013 12:31, "Cipher Chen" >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi everyone, >>>>>>>>>> I have solved a configuration problem due to myself in hadoop >>>>>>>>>> cluster mode. >>>>>>>>>> >>>>>>>>>> I have configuration as below: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> fs.default.name >>>>>>>>>> hdfs://master:54310 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> a >>>>>>>>>> nd the hosts file: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /etc/hosts: >>>>>>>>>> 127.0.0.1 localhost >>>>>>>>>> 192.168.6.10 localhost >>>>>>>>>> ### >>>>>>>>>> >>>>>>>>>> 192.168.6.10 tulip master >>>>>>>>>> 192.168.6.5 violet slave >>>>>>>>>> >>>>>>>>>> a >>>>>>>>>> nd when i was trying to start-dfs.sh, namenode failed to start. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> namenode log hinted that: >>>>>>>>>> 13/09/09 17:09:02 INFO namenode.NameNode: Namenode up at: >>>>>>>>>> localhost/192.168.6.10:54310 >>>>>>>>>> ... >>>>>>>>>> 13/09/09 17:09:10 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 0 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:11 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 1 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:12 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 2 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:13 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 3 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:14 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 4 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:15 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 5 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:16 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 6 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:17 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 7 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:18 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 8 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> 13/09/09 17:09:19 INFO ipc.Client: Retrying connect to server: >>>>>>>>>> localhost/127.0.0.1:54310. Already tried 9 time(s); retry policy >>>>>>>>>> is RetryUpToMaximumCountWithF> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Now I know deleting the line "192.168.6.10 localhost ### >>>>>>>>>> " >>>>>>>>>> would fix this. >>>>>>>>>> But I still don't know >>>>>>>>>> >>>>>>>>>> why hadoop would resolve "master" to "localhost/127.0.0.1." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Seems http://blog.devving.com/why-does-hbase-care-about-etchosts/explains this, >>>>>>>>>> I'm not quite sure. >>>>>>>>>> Is there any >>>>>>>>>> other >>>>>>>>>> explanation to this? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Cipher Chen >>>>>>>>>> >>>>>>>>> >>>>>>>>> CONFIDENTIALITY NOTICE >>>>>>>>> NOTICE: This message is intended for the use of the individual or >>>>>>>>> entity to which it is addressed and may contain information that is >>>>>>>>> confidential, privileged and exempt from disclosure under applicable law. >>>>>>>>> If the reader of this message is not the intended recipient, you are hereby >>>>>>>>> notified that any printing, copying, dissemination, distribution, >>>>>>>>> disclosure or forwarding of this communication is strictly prohibited. If >>>>>>>>> you have received this communication in error, please contact the sender >>>>>>>>> immediately and delete it from your system. Thank You. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jay Vyas >>>>>>> http://jayunit100.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Cipher Chen >>>>> >>>> >>>> >> >> >> -- >> Cipher Chen >> > > -- Cipher Chen --089e013d14ca503ff704e625d70b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, all
=C2=A0 Thanks for all your replies = and guidance.

=C2=A0 Although I haven't figured out why. :)
<= div class=3D"gmail_extra">

On Wed, Sep 11= , 2013 at 4:03 PM, Jitendra Yadav <jeetuyadav200890@gmail.com= > wrote:
Hi,
=C2=A0
So what you were expecting while pinging master?
=C2=A0
As per my understanding it is=C2=A0working fine.Well there is no sense= of using localhost and hostname on same ip, for localhost it's always = preferred to use loopback method i.e 127.0.0.1
=C2=A0
Hope this will help you.
=C2=A0
Regards
Jitendra
On Wed, Sep 11, 2013 at 7:05 AM, Cipher Chen <cipher.chen2012= @gmail.com> wrote:
So
for the first wrong /etc/hosts file, the sequence would be :
<= /div>
find hdfs://master:54310
find master -> 192.168.6.10 (but it already got ip here)
find 192.168.6.10 -> localhost
find localhost -> 127.0.0.1


The other thing, when 'ping master', i would got reply from '= ;192.168.6.10' instead of 127.0.0.1.
So it's not simply the Name Resolution on the os level. Or i'm t= otally wrong?



On Tue, Sep 10, 2013 at 11:13 PM, Vinayakumar B = <vinay.opensource@gmail.com> wrote:

Ensure that for each ip there is only one hostname configure= d in /etc/hosts file.

If you configure multiple different hostnames for same ip th= en os will chose first one when finding hostname using ip. Similarly for ip= using hostname.

Regards,
Vinayakumar B

On Sep 10, 2013 9:27 AM, "Chris Embree"= ; <cembree@gmail.= com> wrote:
This sound entirely like an OS Level problem and is slight= ly outside of the scope of this list, however. =C2=A0I'd suggest you lo= ok at your /etc/nsswitch.conf file and ensure that the hosts: line says=C2= =A0
hosts: files dns=20

This will ensure that names are resolved first by /etc/hosts, then by = DNS.

Please also ensure that all of your systems have the same configuratio= n and that your NN, JT, SNN, etc. are all using the correct/same hostname.<= /div>

This is basic Name Resolution, please do not confuse this with a Hadoo= p issue. IMHO


On Mon, Sep 9, 2013 at 10:05 PM, Cipher Chen <cipher.chen2012@gmail.com> wrote:
Sorry i didn't express it well.

conf/masters:
master

conf/slaves:
master
slave

The /etc/hosts file which caused the problem (start-dfs.sh failed):
<= /div>
127.0.0.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 localhost
192.168.6.10=C2=A0=C2=A0=C2=A0 localhost=20
###

192.168.6.10=C2=A0=C2=A0=C2=A0 tulip master=
192.168.6.5=C2=A0=C2=A0=C2=A0=C2=A0 violet slave

But when I commented the line appended with hash,
127.0.0.1=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 localhost
#=C2=A0=20
192.168.6.10=C2=A0=C2=A0=C2=A0 localhost=20
###

192.168.6.10=C2=A0=C2=A0=C2=A0 tulip master=
192.168.6.5=C2=A0=C2=A0=C2=A0=C2=A0 violet slave

The namenode starts successfully.
I can't figure out why.
How does hadoop decide which host/hostname/ip to be the namenode?

BTW: How could namenode care about conf/masters and conf/slaves,
sin= ce it's the host who run start-dfs.sh would be the namenode.
Namenode doesn't need to check those confs.
Nodes listed in conf/masteres would be SecondaryNameNode, isn't it?<= br>
I


On Mon, Sep 9, 2013 at 10:39 PM, Jitendra Yadav = <jeetuyadav200890@gmail.com> wrote:
Means your $HADOOP_HOME/conf/masters = file content.=20


On Mon, Sep 9, 2013 at 7:52 PM, Jay Vyas <ja= yunit100@gmail.com> wrote:
Jitendra: =C2=A0When you say " check your masters fil= e content" =C2=A0what are you referring to?


On Mon, Sep 9, 2013 at 8:31 AM, Jitendra Yadav <= span dir=3D"ltr"><jeetuyadav200890@gmail.com> wrote:
Also can you please check your masters file content in hadoop conf dir= ectory?
=C2=A0
Regards
JItendra=20

On Mon, Sep 9, 2013 at 5:11 PM, Olivier Renault = <orenault@= hortonworks.com> wrote:

Could you confirm that you put the hash in front of 192.168.= 6.10=C2=A0=C2=A0=C2=A0 localhost

It should look like

# 192.168.6.10=C2=A0=C2=A0=C2=A0 localhost

Thanks
Olivier

On 9 Sep 2013 12:31, "Cipher Chen" <= ;cipher.chen= 2012@gmail.com> wrote:
Hi everyone,
=C2=A0 I have solved a configuration problem due to myself in hadoop clu= ster mode.

I have configuration as below:

=C2=A0 <property>
= =C2=A0=C2=A0=C2=A0 <name>fs.default.name</name>
=C2=A0=C2=A0=C2=A0 <value>hdfs://master:54310</value>
=C2=A0= </property>

a=20
nd the hosts file:


/etc/hosts:
127.0.0.1= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 localhost
192.168.6.10=C2=A0=C2=A0=C2=A0 localhost=20
###

192.168.6.10=C2=A0=C2=A0=C2=A0 tulip master=
192.168.6.5=C2=A0=C2=A0=C2=A0=C2=A0 violet slave

a=20
nd when i was trying to start-dfs.sh, namenode failed to= start.


namenode log hinted that:
13/09/09 17:09:02 INFO name= node.NameNode: Namenode up at: localhost/192.168.6.10:54310
...
13/09/09 17:09:10 INFO ipc.Client: Retrying connect to server: local= host/127.0.0.1:54310<= /a>. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithF>= ;
13/09/09 17:09:11 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Al= ready tried 1 time(s); retry policy is RetryUpToMaximumCountWithF>
13= /09/09 17:09:12 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Alre= ady tried 2 time(s); retry policy is RetryUpToMaximumCountWithF>
13/09/09 17:09:13 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Al= ready tried 3 time(s); retry policy is RetryUpToMaximumCountWithF>
13= /09/09 17:09:14 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Alre= ady tried 4 time(s); retry policy is RetryUpToMaximumCountWithF>
13/09/09 17:09:15 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Al= ready tried 5 time(s); retry policy is RetryUpToMaximumCountWithF>
13= /09/09 17:09:16 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Alre= ady tried 6 time(s); retry policy is RetryUpToMaximumCountWithF>
13/09/09 17:09:17 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Al= ready tried 7 time(s); retry policy is RetryUpToMaximumCountWithF>
13= /09/09 17:09:18 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Alre= ady tried 8 time(s); retry policy is RetryUpToMaximumCountWithF>
13/09/09 17:09:19 INFO ipc.Client: Retrying connect to server: localhost/127.0.0.1:54310. Al= ready tried 9 time(s); retry policy is RetryUpToMaximumCountWithF>
..= .

Now I know deleting the line "192.168.6.10=C2=A0=C2= =A0=C2=A0 localhost=C2=A0 ###
"=20
would fix this.
But I still don't know
=C2=A0=20
why hadoop would resolve "master" to "loc= alhost/127.0.0.1."=


Seems http://blog.devving.com/why-does-hbase-care-abo= ut-etchosts/ explains this,
I'm not quite sure.
Is there any=20
=C2=A0other
explanation to this?

Thanks.


--
Cipher Chen
=
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or e= ntity to which it is addressed and may contain information that is confiden= tial, privileged and exempt from disclosure under applicable law. If the re= ader of this message is not the intended recipient, you are hereby notified= that any printing, copying, dissemination, distribution, disclosure or for= warding of this communication is strictly prohibited. If you have received = this communication in error, please contact the sender immediately and dele= te it from your system. Thank You.




--
Jay Vyas
http://jayunit100.blogspot.com <= /span>



=
--
Cipher Chen




--
Cipher Chen




--
Cipher Chen
--089e013d14ca503ff704e625d70b--