<div dir="ltr"><div dir="ltr">Looks like is_nfs_export_available started failing again in recent centos-regressions.</div><div dir="ltr"><br></div><div dir="ltr">Michael, can you please check?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 5:30 PM Yaniv Kaul &lt;<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 5:15 PM Michael Scherer &lt;<a href="mailto:mscherer@redhat.com" target="_blank">mscherer@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le lundi 22 avril 2019 à 22:57 +0530, Atin Mukherjee a écrit :<br>
&gt; Is this back again? The recent patches are failing regression :-\ .<br>
<br>
So, on builder206, it took me a while to find that the issue is that<br>
nfs (the service) was running.<br>
<br>
./tests/basic/afr/tarissue.t failed, because the nfs initialisation<br>
failed with a rather cryptic message:<br>
<br>
[2019-04-23 13:17:05.371733] I [socket.c:991:__socket_server_bind] 0-<br>
socket.nfs-server: process started listening on port (38465)<br>
[2019-04-23 13:17:05.385819] E [socket.c:972:__socket_server_bind] 0-<br>
socket.nfs-server: binding to  failed: Address already in use<br>
[2019-04-23 13:17:05.385843] E [socket.c:974:__socket_server_bind] 0-<br>
socket.nfs-server: Port is already in use<br>
[2019-04-23 13:17:05.385852] E [socket.c:3788:socket_listen] 0-<br>
socket.nfs-server: __socket_server_bind failed;closing socket 14<br>
<br>
I found where this came from, but a few stuff did surprised me:<br>
<br>
- the order of print is different that the order in the code<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Indeed strange...</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- the message on &quot;started listening&quot; didn&#39;t take in account the fact<br>
that bind failed on:<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Shouldn&#39;t it bail out if it failed to bind?</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Some missing &#39;goto out&#39; around line 975/976?<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Y.</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<a href="https://github.com/gluster/glusterfs/blob/master/rpc/rpc-transport/socket/src/socket.c#L967" rel="noreferrer" target="_blank">https://github.com/gluster/glusterfs/blob/master/rpc/rpc-transport/socket/src/socket.c#L967</a><br>
<br>
The message about port 38465 also threw me off the track. The real<br>
issue is that the service nfs was already running, and I couldn&#39;t find<br>
anything listening on port 38465<br>
<br>
once I do service nfs stop, it no longer failed.<br>
<br>
So far, I do know why nfs.service was activated.<br>
<br>
But at least, 206 should be fixed, and we know a bit more on what would<br>
be causing some failure.<br>
<br>
<br>
<br>
&gt; On Wed, 3 Apr 2019 at 19:26, Michael Scherer &lt;<a href="mailto:mscherer@redhat.com" target="_blank">mscherer@redhat.com</a>&gt;<br>
&gt; wrote:<br>
&gt; <br>
&gt; &gt; Le mercredi 03 avril 2019 à 16:30 +0530, Atin Mukherjee a écrit :<br>
&gt; &gt; &gt; On Wed, Apr 3, 2019 at 11:56 AM Jiffin Thottan &lt;<br>
&gt; &gt; &gt; <a href="mailto:jthottan@redhat.com" target="_blank">jthottan@redhat.com</a>&gt;<br>
&gt; &gt; &gt; wrote:<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; Hi,<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; is_nfs_export_available is just a wrapper around &quot;showmount&quot;<br>
&gt; &gt; &gt; &gt; command AFAIR.<br>
&gt; &gt; &gt; &gt; I saw following messages in console output.<br>
&gt; &gt; &gt; &gt;  mount.nfs: rpc.statd is not running but is required for remote<br>
&gt; &gt; &gt; &gt; locking.<br>
&gt; &gt; &gt; &gt; 05:06:55 mount.nfs: Either use &#39;-o nolock&#39; to keep locks local,<br>
&gt; &gt; &gt; &gt; or<br>
&gt; &gt; &gt; &gt; start<br>
&gt; &gt; &gt; &gt; statd.<br>
&gt; &gt; &gt; &gt; 05:06:55 mount.nfs: an incorrect mount option was specified<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; For me it looks rpcbind may not be running on the machine.<br>
&gt; &gt; &gt; &gt; Usually rpcbind starts automatically on machines, don&#39;t know<br>
&gt; &gt; &gt; &gt; whether it<br>
&gt; &gt; &gt; &gt; can happen or not.<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; That&#39;s precisely what the question is. Why suddenly we&#39;re seeing<br>
&gt; &gt; &gt; this<br>
&gt; &gt; &gt; happening too frequently. Today I saw atleast 4 to 5 such<br>
&gt; &gt; &gt; failures<br>
&gt; &gt; &gt; already.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Deepshika - Can you please help in inspecting this?<br>
&gt; &gt; <br>
&gt; &gt; So we think (we are not sure) that the issue is a bit complex.<br>
&gt; &gt; <br>
&gt; &gt; What we were investigating was nightly run fail on aws. When the<br>
&gt; &gt; build<br>
&gt; &gt; crash, the builder is restarted, since that&#39;s the easiest way to<br>
&gt; &gt; clean<br>
&gt; &gt; everything (since even with a perfect test suite that would clean<br>
&gt; &gt; itself, we could always end in a corrupt state on the system, WRT<br>
&gt; &gt; mount, fs, etc).<br>
&gt; &gt; <br>
&gt; &gt; In turn, this seems to cause trouble on aws, since cloud-init or<br>
&gt; &gt; something rename eth0 interface to ens5, without cleaning to the<br>
&gt; &gt; network configuration.<br>
&gt; &gt; <br>
&gt; &gt; So the network init script fail (because the image say &quot;start eth0&quot;<br>
&gt; &gt; and<br>
&gt; &gt; that&#39;s not present), but fail in a weird way. Network is<br>
&gt; &gt; initialised<br>
&gt; &gt; and working (we can connect), but the dhclient process is not in<br>
&gt; &gt; the<br>
&gt; &gt; right cgroup, and network.service is in failed state. Restarting<br>
&gt; &gt; network didn&#39;t work. In turn, this mean that rpc-statd refuse to<br>
&gt; &gt; start<br>
&gt; &gt; (due to systemd dependencies), which seems to impact various NFS<br>
&gt; &gt; tests.<br>
&gt; &gt; <br>
&gt; &gt; We have also seen that on some builders, rpcbind pick some IP v6<br>
&gt; &gt; autoconfiguration, but we can&#39;t reproduce that, and there is no ip<br>
&gt; &gt; v6<br>
&gt; &gt; set up anywhere. I suspect the network.service failure is somehow<br>
&gt; &gt; involved, but fail to see how. In turn, rpcbind.socket not starting<br>
&gt; &gt; could cause NFS test troubles.<br>
&gt; &gt; <br>
&gt; &gt; Our current stop gap fix was to fix all the builders one by one.<br>
&gt; &gt; Remove<br>
&gt; &gt; the config, kill the rogue dhclient, restart network service.<br>
&gt; &gt; <br>
&gt; &gt; However, we can&#39;t be sure this is going to fix the problem long<br>
&gt; &gt; term<br>
&gt; &gt; since this only manifest after a crash of the test suite, and it<br>
&gt; &gt; doesn&#39;t happen so often. (plus, it was working before some day in<br>
&gt; &gt; the<br>
&gt; &gt; past, when something did make this fail, and I do not know if<br>
&gt; &gt; that&#39;s a<br>
&gt; &gt; system upgrade, or a test change, or both).<br>
&gt; &gt; <br>
&gt; &gt; So we are still looking at it to have a complete understanding of<br>
&gt; &gt; the<br>
&gt; &gt; issue, but so far, we hacked our way to make it work (or so do I<br>
&gt; &gt; think).<br>
&gt; &gt; <br>
&gt; &gt; Deepshika is working to fix it long term, by fixing the issue<br>
&gt; &gt; regarding<br>
&gt; &gt; eth0/ens5 with a new base image.<br>
&gt; &gt; --<br>
&gt; &gt; Michael Scherer<br>
&gt; &gt; Sysadmin, Community Infrastructure and Platform, OSAS<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; --<br>
&gt; <br>
&gt; - Atin (atinm)<br>
-- <br>
Michael Scherer<br>
Sysadmin, Community Infrastructure<br>
<br>
<br>
<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a></blockquote></div></div>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Thanks,<br></div>Sanju<br></div></div>