<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 4:40 PM, Raghavendra Talur <span dir="ltr"><<a href="mailto:raghavendra.talur@gmail.com" target="_blank">raghavendra.talur@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 10:52 AM, Krishnan Parthasarathi <span dir="ltr"><<a href="mailto:kparthas@redhat.com" target="_blank">kparthas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>
> ><br>
> > A port assigned by Glusterd for a brick is found to be in use already by<br>
> > the brick. Any changes in Glusterd recently which can cause this?<br>
> ><br>
> > Or is it a test infra problem?<br>
<br>
</span>This issue is likely to be caused by <a href="http://review.gluster.org/11039" rel="noreferrer" target="_blank">http://review.gluster.org/11039</a><br>
This patch changes the port allocation that happens for rpc_clnt based<br>
connections. Previously, ports allocated where < 1024. With this change,<br>
these connections, typically mount process, gluster-nfs server processes<br>
etc could end up using ports that bricks are being assigned to.<br>
<br>
IIUC, the intention of the patch was to make server processes lenient to<br>
inbound messages from ports > 1024. If we don't require to use ports > 1024<br>
we could leave the port allocation for rpc_clnt connections as before.<br>
Alternately, we could reserve the range of ports starting from 49152 for bricks<br>
by setting net.ipv4.ip_local_reserved_ports using sysctl(8). This is specific to Linux.<br>
I'm not aware of how this could be done in NetBSD for instance though.<br>
</blockquote></div><br><br clear="all"></div></div><div>It seems this is exactly whats happening.</div><div><br></div><div>I have a question, I get the following data from netstat and grep</div><div><br></div><div>tcp 0 0 f6be17c0fbf5:1023 f6be17c0fbf5:24007 ESTABLISHED 31516/glusterfsd<br></div><div>tcp 0 0 f6be17c0fbf5:49152 f6be17c0fbf5:490 ESTABLISHED 31516/glusterfsd<br></div><div>unix 3 [ ] STREAM CONNECTED 988353 31516/glusterfsd /var/run/gluster/4878d6e905c5f6032140a00cc584df8a.socket<br></div><div><br></div><div>Here 31516 is the brick pid. </div><div><br></div><div>Looking at the data, line 2 is very clear, it shows connection between brick and glusterfs client.</div><div>unix socket on line 3 is also clear, it is the unix socket connection that glusterd and brick process use for communication.</div><div><br></div><div>I am not able to understand line 1; which part of brick process established a tcp connection with glusterd using port 1023?</div><div>Note: this data is from a build which does not have the above mentioned patch.</div></div></div></blockquote><div><br></div><div><br></div><div><div>The patch which exposed this bug is being reverted till the underlying bug is also fixed.</div><div>You can monitor revert patches here </div><div>master: <a href="http://review.gluster.org/11507">http://review.gluster.org/11507</a></div><div>3.7 branch: <a href="http://review.gluster.org/11508">http://review.gluster.org/11508</a></div><div><br></div><div>Please rebase your patches after the above patches are merged to ensure that you patches pass regression.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><font color="#888888"><div><br></div>-- <br><div><div dir="ltr"><font color="#666666"><b>Raghavendra Talur </b></font><div><br></div></div></div>
</font></span></div></div>
</blockquote></div><br><div class="gmail_signature"><div dir="ltr"><div><br></div></div></div>
</div></div>