<div style="color:#000; font-size: 14px;font-family: arial;"><div>I have checked all the config files are the same, except bindnetaddr.</div><div>So I'm sending only logs.</div><div><br></div><div><br></div><div><br></div></div><!-- jy5ContentSuffix --><div>在2017年03月16 15时54分, "Jan Friesse"&lt;jfriesse@redhat.com&gt;写道:</div><blockquote id="isReplyContent" style="padding-left: 1ex; margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);"><br>&gt; corosync.conf and debug logs are in attachment.<br><br>Thanks for them. They look really interesting. As can be seen<br><br>Mar 14 11:37:28 [57827] node-132.acloud.vt corosync debug &nbsp; [TOTEM ] <br>timer_function_orf_token_timeout The token was lost in the<br> &nbsp;OPERATIONAL state.<br><br>corosync correctly detected token lost. Also<br><br>Mar 14 11:44:41 [57827] node-132.acloud.vt corosync debug &nbsp; [TOTEM ] <br>memb_state_gather_enter entering GATHER state from 11(merg<br>e during join).<br><br>says it correctly detected merge. But since then it's becoming weird.<br>Mar 14 11:44:54 [57827] node-132.acloud.vt corosync debug &nbsp; [TOTEM ] <br>memb_state_gather_enter entering GATHER state from 0(conse<br>nsus timeout).<br>Mar 14 11:45:06 [57827] node-132.acloud.vt corosync debug &nbsp; [TOTEM ] <br>memb_state_gather_enter entering GATHER state from 0(conse<br>nsus timeout).<br>...<br>Mar 14 12:55:47 [154709] node-132.acloud.vt corosync debug &nbsp; [TOTEM ] <br>memb_state_gather_enter entering GATHER state from 0(cons<br>ensus timeout)<br><br>So even after two other nodes merged, there is still something what <br>prevents corosync to reach consensus.<br><br>Would it be possible to attach also other nodes logs/configs?<br><br>For now I guess reason can be one ofe:<br>- ifdown on one of other nodes which made whole membership broken<br>- different node list in config between nodes<br>- "forget" node with node list containing one of the 200.201.162.x nodes<br><br>Regards,<br> &nbsp; Honza<br>&gt;<br>&gt; And two messages from kernel:<br>&gt;<br>&gt; 2017-03-14 11:37:20.097233 - info &nbsp;e1000: eth0 NIC Link is Down<br>&gt;<br>&gt; 2017-03-14 11:44:41.032121 - info &nbsp;e1000: eth0 NIC Link is Up 1000 Mbps<br>&gt; Full Duplex, Flow Control: RX<br>&gt;<br>&gt;<br>&gt; Thanks.<br>&gt;<br>&gt;<br>&gt; On 2017/3/15 16:29, Jan Friesse wrote:<br>&gt;&gt;&gt; Yesterday I found corosync took almost one hour to form a cluster(a<br>&gt;&gt;&gt; failed node came back online).<br>&gt;&gt;<br>&gt;&gt; This for sure shouldn't happen (at least with default timeout settings).<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; So I captured some corosync packets, and opened the pcap file in<br>&gt;&gt;&gt; wireshark.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; But wireshark only displayed raw udp, no totem.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Wireshark version is 2.2.5. I'm sure it supports corosync totem.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; corosync is 2.4.0.<br>&gt;&gt;<br>&gt;&gt; Wireshark has corosync dissector, but only for version 1.x. 2.x is not<br>&gt;&gt; supported yet.<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; And if corosync takes too long to form a cluster, how to diagnose it?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I read the logs, but could not figure it out.<br>&gt;&gt;<br>&gt;&gt; Logs, specially when debug is enabled, has usually enough info. Can<br>&gt;&gt; paste your config + logs?<br>&gt;&gt;<br>&gt;&gt; Regards,<br>&gt;&gt; &nbsp; Honza<br>&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>&gt;&gt;&gt; http://lists.clusterlabs.org/mailman/listinfo/users<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Project Home: http://www.clusterlabs.org<br>&gt;&gt;&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt;&gt;&gt; Bugs: http://bugs.clusterlabs.org<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; _______________________________________________<br>&gt;&gt; Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>&gt;&gt; http://lists.clusterlabs.org/mailman/listinfo/users<br>&gt;&gt;<br>&gt;&gt; Project Home: http://www.clusterlabs.org<br>&gt;&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt;&gt; Bugs: http://bugs.clusterlabs.org<br>&gt;<br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>&gt; http://lists.clusterlabs.org/mailman/listinfo/users<br>&gt;<br>&gt; Project Home: http://www.clusterlabs.org<br>&gt; Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>&gt; Bugs: http://bugs.clusterlabs.org<br>&gt;<br><br><br>_______________________________________________<br>Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>http://lists.clusterlabs.org/mailman/listinfo/users<br><br>Project Home: http://www.clusterlabs.org<br>Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf<br>Bugs: http://bugs.clusterlabs.org<br></blockquote>