Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Date: Wed, 6 Apr 2016 10:29:25 +0000 (UTC)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: common-dev@hadoop.apache.org
Message-ID: <JIRA.12956453.1459938553000.149013.1459938565565@Atlassian.JIRA>
In-Reply-To: <JIRA.12956453.1459938553000@Atlassian.JIRA>
References: <JIRA.12956453.1459938553000@Atlassian.JIRA>
 <JIRA.12956453.1459938553684@arcas>
Subject: [jira] [Created] (HADOOP-13005) if local hostname doesn't resolve,
 HttpServer2 fails with a kerberos exception
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Steve Loughran created HADOOP-13005:
---------------------------------------

             Summary: if local hostname doesn't resolve, HttpServer2 fails with a kerberos exception
                 Key: HADOOP-13005
                 URL: https://issues.apache.org/jira/browse/HADOOP-13005
             Project: Hadoop Common
          Issue Type: Bug
          Components: net
    Affects Versions: 2.7.2
         Environment: a VM whose hostname was no longer in /etc/hosts
            Reporter: Steve Loughran
            Priority: Minor


When a service (NN, DN) is started and the local hostname isn't in /etc/hosts, things will, obviously, fail.

However, the failure is reported as a wrapped Kerberos Exception, rather than going via the NetUtils.wrapException handling code {{java.lang.RuntimeException: Could not resolve Kerberos principal name: java.net.UnknownHostException: xubunty: xubunty: unknown error}}

The text is a dangerous distraction from the real cause. Especially as it appears even on systems which aren't running kerberos.

A fail-fast check could go into the http server startup process ahead of the security setup; NetUtils could add special reporting of the unknown-local-host problem


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)