From debbugs-submit-bounces@debbugs.gnu.org Sun May 16 14:26:32 2021 Received: (at submit) by debbugs.gnu.org; 16 May 2021 18:26:32 +0000 Received: from localhost ([127.0.0.1]:51458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1liLTE-0002n9-5G for submit@debbugs.gnu.org; Sun, 16 May 2021 14:26:32 -0400 Received: from lists.gnu.org ([209.51.188.17]:40602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1liLTD-0002n2-2G for submit@debbugs.gnu.org; Sun, 16 May 2021 14:26:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1liLTC-00028q-TL for bug-guix@gnu.org; Sun, 16 May 2021 14:26:30 -0400 Received: from mira.cbaines.net ([212.71.252.8]:56692) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1liLTA-0005Ms-Op; Sun, 16 May 2021 14:26:30 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id 64FE527BC78; Sun, 16 May 2021 19:26:26 +0100 (BST) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 835715d7; Sun, 16 May 2021 18:26:25 +0000 (UTC) References: <87lf8e4l42.fsf@gnu.org> User-agent: mu4e 1.4.15; emacs 27.1 From: Christopher Baines To: Mathieu Othacehe Subject: Re: bug#48468: substitute server connection timeout In-reply-to: <87lf8e4l42.fsf@gnu.org> Date: Sun, 16 May 2021 19:26:22 +0100 Message-ID: <87eee6cz75.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: bug-guix@gnu.org, 48468@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain Mathieu Othacehe writes: > Hello, > > We recently have a lot of those errors on Cuirass: > > --8<---------------cut here---------------start------------->8--- > guix substitute: warning: while fetching http://141.80.167.131:5557/nar/g7ka09613k5v1vlznh87yg35905ggw51-python2-scipy-1.2.2-guile-builder: server is somewhat slow > guix substitute: warning: try `--no-substitutes' if the problem persists > guix substitute: error: connect*: Connection timed out > --8<---------------cut here---------------end--------------->8--- > > which means that the workers are failing to connect to the Cuirass > remote-server publish server on berlin at 141.80.167.131:5557. > > Stracing this publish server shows that connection reuse seems to be > broken: > > --8<---------------cut here---------------start------------->8--- > accept4(9, {sa_family=AF_INET, sin_port=htons(41742), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41744), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41746), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 25 > accept4(9, {sa_family=AF_INET, sin_port=htons(41748), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 24 > accept4(9, {sa_family=AF_INET, sin_port=htons(41750), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41752), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41754), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 25 > accept4(9, {sa_family=AF_INET, sin_port=htons(41756), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41758), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 26 > accept4(9, {sa_family=AF_INET, sin_port=htons(41760), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 24 > accept4(9, {sa_family=AF_INET, sin_port=htons(41762), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41764), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41766), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41768), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 22 > accept4(9, {sa_family=AF_INET, sin_port=htons(41770), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41772), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41774), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41776), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41778), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41780), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > accept4(9, {sa_family=AF_INET, sin_port=htons(41782), sin_addr=inet_addr("141.80.167.185")}, [112->16], 0) = 21 > --8<---------------cut here---------------end--------------->8--- > > Investigating it, I found that the connection is closed and opened > multiple times in the call-with-cached-connection procedure of the (guix > script substitute) module. > > It looks like its because a 'bad-headers exception is raised when trying > to parse an eof object: > > --8<---------------cut here---------------start------------->8--- > ;;; (error bad-header (read-header-line #)) > --8<---------------cut here---------------end--------------->8--- > > I'm not sure where this eof comes from. There is this comment in the > http-multiple-get procedure in (guix http-client): > > --8<---------------cut here---------------start------------->8--- > ;; Swallow networking errors that could occur due to connection reuse > ;; and the like; they will be handled down the road when trying to > ;; read responses. > (false-if-networking-error > (begin > (for-each (cut write-request <> buffer) batch) > (put-bytevector p (get)) > (force-output p)))) > --8<---------------cut here---------------end--------------->8--- > > which would suggest that connection reuse could cause networking errors? > > What also puzzles me it that the main guix publish server on berlin does > not seem to present this issue. That would indicate that this error is > caused by how the Cuirass remote-server publish server is started or > configured. > > Ludo, Chris, any idea? While I've been working in this area, I've actually been trying to pick apart the connection caching, since the single thread assumption doesn't hold in the Guix Build Coordinator. Anyway, I do have a theory. Assuming I'm correct in saying that there's no nginx between the client and publish server here, I think that's your configuration difference. For ci.guix.gnu.org, as well as data.guix.gnu.org, it's NGinx which is keeping connections alive. I'm not sure the Guile code for the publish server does similarly, so talking to it directly might be different. That's on the server side, the actual problem is probably on the client side, as I guess there are possibly places where closed connections aren't handled properly. This reminds me I sent some patches relating to closing connections, this could well be related [1]. 1: https://issues.guix.gnu.org/47174 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmChY89fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfG9w/+KvzCHwfnB+eeEd6i0xTvTfc8+oLxb+GS j1TSbXSGR02ByGMGIbJeAMmNPV20V9Lzi24a49451fskUZbCGeg6aS2rO3c9QpUX jbF7//NW8zwgmhO/Hh9dvB4v+q01+VwrzE3c6ssAVO6772ZrTJqGA7oCU9UqD1w6 dQYUto8iSxa95UhFcNFMtGcBAevdoN4Ku9OpkqIt8uViCED+YM6a9Ej4d9f9oC8h vxw6EU0YsCrobJQJ8KW56N9uR4oeI4IqWevou2LbSAmcHEWmGHAF6XDgxu0594Ip YOFuqso4nuRxU3ffzgEupMbJA07yrwf0EB4lreqsSfU8gtZupFMLgyc8PviyXjw3 XPpo3PAukKhsVZyQlnTc6ldatWWVHIeTPy8vxdr6GvSQnzliaQmzpHj7xVqkfS3f R1gz5hEXoS0o/CXpVkpnaYMC8m+Y2ujM5AbEUBVo6itR6mmUCCF5D9q/BtosjQvu 8wrLes42iAqwlnNeg8UGKra/cwJ0YGVrOInsOyXX97jz3UVjkxV7jq53+vkw3fGZ eyHDugAJ8DKw9js8BX88AmXaV/Art4M0qG6D6Zp+MvIUbU9z+oNeTjAXgGewxntw sfIdxHju+DNs5x5je3pTzyRSDPEfle8Xvd58DbGyAIoP8v7C7LYPmxVID7R0D/cs ccIQKCj/kqg= =yVQQ -----END PGP SIGNATURE----- --=-=-=--