<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>
<head>
  <meta name="Generator" content="Zarafa WebAccess v7.1.14-51822">
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <title>RE: [Gluster-users] BUG: After stop and start wrong port is advertised</title>
  <style type="text/css">
      body
      {
        font-family: Arial, Verdana, Sans-Serif ! important;
        font-size: 12px;
        padding: 5px 5px 5px 5px;
        margin: 0px;
        border-style: none;
        background-color: #ffffff;
      }

      p, ul, li
      {
        margin-top: 0px;
        margin-bottom: 0px;
      }
  </style>
</head>
<body>
<p>Hi Darrell,</p><p>&nbsp;</p><p>&nbsp;</p><p>Thanks, for us it&#39;s really easy to reproduce atm. Each restart or stop/start is causing the issue atm over here.</p><p>&nbsp;</p><p>Atin will look into it on monday fortunately :)</p><p><br /><br />Regards</p><p>Jo</p><p>&nbsp;</p><p>&nbsp;</p><p><br />&nbsp;</p><blockquote style="border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-----Original message-----<br /><strong>From:</strong>        Darrell Budic &lt;budic@onholyground.com&gt;<br /><strong>Sent:</strong>        Fri 22-09-2017 17:24<br /><strong>Subject:</strong>        Re: [Gluster-users] BUG: After stop and start wrong port is advertised<br /><strong>To:</strong>        Atin Mukherjee &lt;amukherj@redhat.com&gt;; <br /><strong>CC:</strong>        Jo Goossens &lt;jo.goossens@hosted-power.com&gt;; gluster-users@gluster.org; <br />I encountered this once in the past, an additional symptom was peers were in disconnected state on the peers that were NOT using the wrong ports. Disconnected peers is how it detected it in the first place.<br /><br />It happened to me after rebooting, and I fixed it but wasn&rsquo;t able to stop and gather debugging info on the time.<br /><br />The problem seemed to be that the volume files in /var/lib/glusterd/vols/&lt;vol-name&gt;//bricks/&lt;server name&gt;\:-v0-&lt;vol name&gt;-brick0 were not updated to reflect a new port # after the restart (and the port numbers had changed to adding and deleting volumes since last start). I stopped glusterd, killed any remaining glusterfsd&rsquo;s, hand edited the files to reflect the new ports they thought they were running the bricks on (from vol info I think, maybe log files) and restarted glusterd, then everything was happy again.<br /><br />Hope it helps, sounds like it may be a bug to me too if others are seeing it.<br /><br /> &nbsp;-Darrell<br /><br /><br />&gt; On Sep 22, 2017, at 8:10 AM, Atin Mukherjee &lt;amukherj@redhat.com&gt; wrote:<br />&gt; <br />&gt; I&#39;ve already replied to your earlier email. In case you&#39;ve not seen it in your mailbox here it goes:<br />&gt; <br />&gt; This looks like a bug to me. For some reason glusterd&#39;s portmap is referring to a stale port (IMO) where as brick is still listening to the correct port. But ideally when glusterd service is restarted, all the portmap in-memory is rebuilt. I&#39;d request for the following details from you to let us start analysing it:<br />&gt; <br />&gt; 1. glusterd statedump output from 192.168.140.43 . You can use kill -SIGUSR2 &lt;pid of glusterd&gt; to request for a statedump and the file will be available in /var/run/gluster<br />&gt; 2. glusterd, brick logfile for 192.168.140.43:/gluster/public from 192.168.140.43<br />&gt; 3. cmd_history logfile from all the nodes.<br />&gt; 4. Content of /var/lib/glusterd/vols/public/<br />&gt; <br />&gt; <br />&gt; On Thu, Sep 21, 2017 at 2:08 PM, Jo Goossens &lt;jo.goossens@hosted-power.com&gt; wrote:<br />&gt; Hi,<br />&gt; <br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; We use glusterfs 3.10.5 on Debian 9.<br />&gt; <br />&gt; &nbsp;<br />&gt; When we stop or restart the service, e.g.: service glusterfs-server restart<br />&gt; <br />&gt; &nbsp;<br />&gt; We see that the wrong port get&#39;s advertised afterwards. For example:<br />&gt; <br />&gt; &nbsp;<br />&gt; Before restart:<br />&gt; <br />&gt; &nbsp;<br />&gt; Status of volume: public<br />&gt; Gluster process &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TCP Port &nbsp;RDMA Port &nbsp;Online &nbsp;Pid<br />&gt; ------------------------------------------------------------------------------<br />&gt; Brick 192.168.140.41:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49153 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 6364<br />&gt; Brick 192.168.140.42:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49152 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 1483<br />&gt; Brick 192.168.140.43:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49152 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 5913<br />&gt; Self-heal Daemon on localhost &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 5932<br />&gt; Self-heal Daemon on 192.168.140.42 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 13084<br />&gt; Self-heal Daemon on 192.168.140.41 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 15499<br />&gt; &nbsp;<br />&gt; Task Status of Volume public<br />&gt; ------------------------------------------------------------------------------<br />&gt; There are no active volume tasks<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; After restart of the service on one of the nodes (192.168.140.43) the port seems to have changed (but it didn&#39;t):<br />&gt; &nbsp;<br />&gt; root@app3:/var/log/glusterfs# &nbsp;gluster volume status<br />&gt; Status of volume: public<br />&gt; Gluster process &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; TCP Port &nbsp;RDMA Port &nbsp;Online &nbsp;Pid<br />&gt; ------------------------------------------------------------------------------<br />&gt; Brick 192.168.140.41:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49153 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 6364<br />&gt; Brick 192.168.140.42:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49152 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 1483<br />&gt; Brick 192.168.140.43:/gluster/public &nbsp; &nbsp; &nbsp; &nbsp;49154 &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 5913<br />&gt; Self-heal Daemon on localhost &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 4628<br />&gt; Self-heal Daemon on 192.168.140.42 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 3077<br />&gt; Self-heal Daemon on 192.168.140.41 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;N/A &nbsp; &nbsp; &nbsp; N/A &nbsp; &nbsp; &nbsp; &nbsp;Y &nbsp; &nbsp; &nbsp; 28777<br />&gt; &nbsp;<br />&gt; Task Status of Volume public<br />&gt; ------------------------------------------------------------------------------<br />&gt; There are no active volume tasks<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; However the active process is STILL the same pid AND still listening on the old port<br />&gt; &nbsp;<br />&gt; root@192.168.140.43:/var/log/glusterfs# netstat -tapn | grep gluster<br />&gt; tcp &nbsp; &nbsp; &nbsp; &nbsp;0 &nbsp; &nbsp; &nbsp;0 0.0.0.0:49152 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0.0.0.0:* &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; LISTEN &nbsp; &nbsp; &nbsp;5913/glusterfsd<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; The other nodes logs fill up with errors because they can&#39;t reach the daemon anymore. They try to reach it on the &quot;new&quot; port instead of the old one:<br />&gt; &nbsp;<br />&gt; [2017-09-21 08:33:25.225006] E [socket.c:2327:socket_connect_finish] 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection refused); disconnecting socket<br />&gt; [2017-09-21 08:33:29.226633] I [rpc-clnt.c:2000:rpc_clnt_reconfig] 0-public-client-2: changing port to 49154 (from 0)<br />&gt; [2017-09-21 08:33:29.227490] E [socket.c:2327:socket_connect_finish] 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection refused); disconnecting socket<br />&gt; [2017-09-21 08:33:33.225849] I [rpc-clnt.c:2000:rpc_clnt_reconfig] 0-public-client-2: changing port to 49154 (from 0)<br />&gt; [2017-09-21 08:33:33.236395] E [socket.c:2327:socket_connect_finish] 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection refused); disconnecting socket<br />&gt; [2017-09-21 08:33:37.225095] I [rpc-clnt.c:2000:rpc_clnt_reconfig] 0-public-client-2: changing port to 49154 (from 0)<br />&gt; [2017-09-21 08:33:37.225628] E [socket.c:2327:socket_connect_finish] 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection refused); disconnecting socket<br />&gt; [2017-09-21 08:33:41.225805] I [rpc-clnt.c:2000:rpc_clnt_reconfig] 0-public-client-2: changing port to 49154 (from 0)<br />&gt; [2017-09-21 08:33:41.226440] E [socket.c:2327:socket_connect_finish] 0-public-client-2: connection to 192.168.140.43:49154 failed (Connection refused); disconnecting socket<br />&gt; &nbsp;<br />&gt; So they now try 49154 instead of the old 49152 <br />&gt; &nbsp;<br />&gt; Is this also by design? We had a lot of issues because of this recently. We don&#39;t understand why it starts advertising a completely wrong port after stop/start.<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; &nbsp;<br />&gt; Regards<br />&gt; <br />&gt; Jo Goossens<br />&gt; <br />&gt; &nbsp;<br />&gt; <br />&gt; _______________________________________________<br />&gt; Gluster-users mailing list<br />&gt; Gluster-users@gluster.org<br />&gt; http://lists.gluster.org/mailman/listinfo/gluster-users<br />&gt; <br />&gt; _______________________________________________<br />&gt; Gluster-users mailing list<br />&gt; Gluster-users@gluster.org<br />&gt; http://lists.gluster.org/mailman/listinfo/gluster-users<br /><br /></blockquote>
</body>
</html>