<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I&#39;m not convinced this is solved. Just had what I believe is a similar failure:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><pre class="gmail-console-output"><span class="gmail-timestamp"><b>00:12:02.532</b> </span>A dependency job for rpc-statd.service failed. See &#39;journalctl -xe&#39; for details.
<span class="gmail-timestamp"><b>00:12:02.532</b> </span>mount.nfs: rpc.statd is not running but is required for remote locking.
<span class="gmail-timestamp"><b>00:12:02.532</b> </span>mount.nfs: Either use &#39;-o nolock&#39; to keep locks local, or start statd.
<span class="gmail-timestamp"><b>00:12:02.532</b> </span>mount.nfs: an incorrect mount option was specified<br><br></pre><pre class="gmail-console-output">(of course, it can always be my patch!)<br><br><a href="https://build.gluster.org/job/centos7-regression/5384/console">https://build.gluster.org/job/centos7-regression/5384/console</a><br><br></pre></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 6:56 PM Atin Mukherjee &lt;<a href="mailto:amukherj@redhat.com">amukherj@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">Thanks misc. I have always seen a pattern that on a reattempt (recheck centos) the same builder is picked up many time even though it&#39;s promised to pick up the builders in a round robin manner.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 7:24 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 jeudi 04 avril 2019 à 15:19 +0200, Michael Scherer a écrit :<br>
&gt; Le jeudi 04 avril 2019 à 13:53 +0200, Michael Scherer a écrit :<br>
&gt; &gt; Le jeudi 04 avril 2019 à 16:13 +0530, Atin Mukherjee a écrit :<br>
&gt; &gt; &gt; Based on what I have seen that any multi node test case will fail<br>
&gt; &gt; &gt; and<br>
&gt; &gt; &gt; the<br>
&gt; &gt; &gt; above one is picked first from that group and If I am correct<br>
&gt; &gt; &gt; none<br>
&gt; &gt; &gt; of<br>
&gt; &gt; &gt; the<br>
&gt; &gt; &gt; code fixes will go through the regression until this is fixed. I<br>
&gt; &gt; &gt; suspect it<br>
&gt; &gt; &gt; to be an infra issue again. If we look at<br>
&gt; &gt; &gt; <a href="https://review.gluster.org/#/c/glusterfs/+/22501/" rel="noreferrer" target="_blank">https://review.gluster.org/#/c/glusterfs/+/22501/</a> &amp;<br>
&gt; &gt; &gt; <a href="https://build.gluster.org/job/centos7-regression/5382/" rel="noreferrer" target="_blank">https://build.gluster.org/job/centos7-regression/5382/</a> peer<br>
&gt; &gt; &gt; handshaking is<br>
&gt; &gt; &gt; stuck as 127.1.1.1 is unable to receive a response back, did we<br>
&gt; &gt; &gt; end<br>
&gt; &gt; &gt; up<br>
&gt; &gt; &gt; having firewall and other n/w settings screwed up? The test never<br>
&gt; &gt; &gt; fails<br>
&gt; &gt; &gt; locally.<br>
&gt; &gt; <br>
&gt; &gt; The firewall didn&#39;t change, and since the start has a line:<br>
&gt; &gt; &quot;-A INPUT -i lo -j ACCEPT&quot;, so all traffic on the localhost<br>
&gt; &gt; interface<br>
&gt; &gt; work. (I am not even sure that netfilter do anything meaningful on<br>
&gt; &gt; the<br>
&gt; &gt; loopback interface, but maybe I am wrong, and not keen on looking<br>
&gt; &gt; kernel code for that).<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; Ping seems to work fine as well, so we can exclude a routing issue.<br>
&gt; &gt; <br>
&gt; &gt; Maybe we should look at the socket, does it listen to a specific<br>
&gt; &gt; address or not ?<br>
&gt; <br>
&gt; So, I did look at the 20 first ailure, removed all not related to<br>
&gt; rebal-all-nodes-migrate.t and seen all were run on builder203, who<br>
&gt; was<br>
&gt; freshly reinstalled. As Deepshika noticed today, this one had a issue<br>
&gt; with ipv6, the 2nd issue we were tracking.<br>
&gt; <br>
&gt; Summary, rpcbind.socket systemd unit listen on ipv6 despites ipv6<br>
&gt; being<br>
&gt; disabled, and the fix is to reload systemd. We have so far no idea on<br>
&gt; why it happen, but suspect this might be related to the network issue<br>
&gt; we did identify, as that happen only after a reboot, that happen only<br>
&gt; if a build is cancelled/crashed/aborted.<br>
&gt; <br>
&gt; I apply the workaround on builder203, so if the culprit is that<br>
&gt; specific issue, guess that&#39;s fixed. <br>
&gt; <br>
&gt; I started a test to see how it go:<br>
&gt; <a href="https://build.gluster.org/job/centos7-regression/5383/" rel="noreferrer" target="_blank">https://build.gluster.org/job/centos7-regression/5383/</a><br>
<br>
The test did just pass, so I would assume the problem was local to<br>
builder203. Not sure why it was always selected, except because this<br>
was the only one that failed, so was always up for getting new jobs. <br>
<br>
Maybe we should increase the number of builder so this doesn&#39;t happen,<br>
as I guess the others builders were busy at that time ?<br>
<br>
-- <br>
Michael Scherer<br>
Sysadmin, Community Infrastructure and Platform, OSAS<br>
<br>
<br>
</blockquote></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>