You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Eric Sirianni (JIRA)" <ji...@apache.org> on 2013/12/16 19:49:09 UTC

[jira] [Commented] (HADOOP-7198) Hadoop defaults for web UI ports often fall smack in the middle of Linux ephemeral port range

    [ https://issues.apache.org/jira/browse/HADOOP-7198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849578#comment-13849578 ] 

Eric Sirianni commented on HADOOP-7198:
---------------------------------------

+1

I've hit this several times now in our automated test environment when restarting the daemons.  As Philip says, the default ports for most Hadoop daemons (e.g. 50010 for DataNode, etc.) fall within Linux's ephemeral port range.  What's the downside to making the Hadoop default ports less than 32768 to remove the possibility of conflict with ephemeral ports?

> Hadoop defaults for web UI ports often fall smack in the middle of Linux ephemeral port range
> ---------------------------------------------------------------------------------------------
>
>                 Key: HADOOP-7198
>                 URL: https://issues.apache.org/jira/browse/HADOOP-7198
>             Project: Hadoop Common
>          Issue Type: Wish
>            Reporter: Philip Zeyliger
>            Priority: Trivial
>
> It turns out (see http://en.wikipedia.org/wiki/Ephemeral_port and  /proc/sys/net/ipv4/ip_local_port_range) that when you bind to port 0, Linux chooses an ephemeral port.  On my default-ridden Ubuntu Maverick box and on CentOS 5.5, that range is 32768-61000.  So, when HBase binds to 60030 or when mapReduce binds to 50070, there's a small chance that you'll conflict with, say, an FTP session, or with some other Hadoop daemon that's had a listening address configured as :0.
> I don't know that there's a practical resolution here, since changing the defaults seems like an ill-fated effort, but if you have any ephemeral port use, you can run into this.  We've now run into it once.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)