From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id C332F62512 for ; Wed, 30 Sep 2020 08:26:58 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B20CA15055 for ; Wed, 30 Sep 2020 08:26:28 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 129E315048 for ; Wed, 30 Sep 2020 08:26:27 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D68E645941; Wed, 30 Sep 2020 08:26:26 +0200 (CEST) To: Proxmox VE development discussion , Alexandre DERUMIER References: <216436814.339545.1599142316781.JavaMail.zimbra@odiso.com> <1601368526.gv9th0ekl0.astroid@nora.none> <1140250655.1944706.1601372261446.JavaMail.zimbra@odiso.com> <1740926248.1973796.1601376764334.JavaMail.zimbra@odiso.com> <596957573.1989195.1601379788390.JavaMail.zimbra@odiso.com> <528275552.1989337.1601380258730.JavaMail.zimbra@odiso.com> <1601385859.kkbi3kzm1m.astroid@nora.none> <2038102437.1994930.1601387538948.JavaMail.zimbra@odiso.com> <1030723475.2207793.1601446155192.JavaMail.zimbra@odiso.com> From: Thomas Lamprecht Message-ID: <02c1eb70-29b4-3038-c269-997909dc48ad@proxmox.com> Date: Wed, 30 Sep 2020 08:26:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Thunderbird/82.0 MIME-Version: 1.0 In-Reply-To: <1030723475.2207793.1601446155192.JavaMail.zimbra@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.164 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] corosync bug: cluster break after 1 node clean shutdown X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 06:26:58 -0000 Hi, On 30.09.20 08:09, Alexandre DERUMIER wrote: > some news, my last test is running for 14h now, and I don't have had an= y problem :) >=20 great! Thanks for all your testing time, this would have been much harder= , if even possible at all, without you probiving so much testing effort on = a production(!) cluster - appreciated! Naturally many thanks to Fabian too, for reading so many logs without goi= ng insane :-) > So, it seem that is indeed fixed ! Congratulations ! >=20 honza comfirmed Fabians suspicion about lacking guarantees of thread safe= ty for cpg_mcast_joined, which was sadly not documented, so this is surely a bug, let's hope the last of such hard to reproduce ones. >=20 >=20 > I wonder if it could be related to this forum user > https://forum.proxmox.com/threads/proxmox-6-2-corosync-3-rare-and-spont= aneous-disruptive-udp-5405-storm-flood.75871/ >=20 > His problem is that after corosync lag (he's have 1 cluster stretch on = 2DC with 10km distance, so I think sometimes he's having some small lag, > 1 node is flooding other nodes with a lot of udp packets. (and making t= hings worst, as corosync cpu is going to 100% / overloaded, and then can'= t see other onodes I can imagine this problem showing up as a a side effect of a flood where= partition changes happen. Not so sure that this can be the cause of that directly. >=20 > I had this problem 6month ago after shutting down a node, that's why I'= m thinking it could "maybe" related. >=20 > So, I wonder if it could be same pmxcfs bug, when something looping or = send again again packets. >=20 > The forum user seem to have the problem multiple times in some week, so= maybe he'll be able to test the new fixed pmxcs, and tell us if it's fix= ing this bug too. Testing once available would be sure a good idea for them.