From owner-freebsd-git@freebsd.org Mon Nov 30 21:24:52 2020 Return-Path: Delivered-To: freebsd-git@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 776654A8C90 for ; Mon, 30 Nov 2020 21:24:52 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ClJCm23phz4k4M; Mon, 30 Nov 2020 21:24:51 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 0AULOoeX000777 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Nov 2020 22:24:50 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Mon, 30 Nov 2020 22:24:50 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: =?utf-8?B?RGF2w63DsA==?= Steinn Geirsson Cc: Li-Wen Hsu , freebsd-git@freebsd.org Subject: Re: 504 errors from cgit-beta Message-ID: References: <20201112155659.GQ913@mail> <20201113.032709.2108746957258946268.yasu@utahime.org> <20201130150642.GB6221@mail> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201130150642.GB6221@mail> User-Agent: Mutt/2.0.1 (2020-11-14) X-Rspamd-Queue-Id: 4ClJCm23phz4k4M X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-git@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion of git use in the FreeBSD project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 21:24:52 -0000 On Mon, 2020-11-30 at 15:06:42 +0000, Davíð Steinn Geirsson wrote: >On Fri, Nov 13, 2020 at 05:33:12PM +0800, Li-Wen Hsu wrote: >> On Fri, Nov 13, 2020 at 2:28 AM Yasuhiro KIMURA wrote: >> > >> > From: Davíð Steinn Geirsson >> > Subject: 504 errors from cgit-beta >> > Date: Thu, 12 Nov 2020 15:56:59 +0000 >> > >> > > We are getting frequent 504 errors when running `git fetch` against an >> > > existing checkout of `ports.git` from https://cgit-beta.freebsd.org/ports.git: >> > > >> > > ``` >> > > $ git fetch cgit-beta >> > > error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 >> > > fatal: the remote end hung up unexpectedly >> > > ``` >> > >> > I experienced same error when accessing Emacs git remository with >> > HTTPS. Following is bug report that I submitted to report the issue. >> > >> > https://savannah.nongnu.org/support/?110322 >> > >> > As you can see, site administrator fixed the issue by icreasing >> > `fastcgi_read_timeout` and `proxy_read_timeout` parameters of >> > nginx. Since cgit-beta also uses nginx this may also fix your >> > error. In my case, however, access always failed and never >> > succeeded. So cause may be different from the one of my case. >> >> Thanks, I have checked this, indeed some requests' handlers don't have >> a long enough timeout setting and I've relaxed them. Hope this solves >> some people's issues. Please check it again, and if it still fails for >> you, we might need to have more information to debug. > >This problem disappeared after your changes, but as of this weekend seems >to be happening again: > >user@ssh:~/foo/ports$ git fetch -v cgit-beta >POST git-upload-pack (gzip 3272 to 1703 bytes) >POST git-upload-pack (gzip 2577 to 1354 bytes) >error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out >fatal: the remote end hung up unexpectedly > >Is it possible some web server config got overwritten during the last >batch of changes? This is most definitely fallout from the commit hashes changing. That means your client will upload basically all the hashes or packs for the server to compare what it does and does not have. What is your up/downstream bandwidth situation like? Could you try some more tracing as outlined here: https://stackoverflow.com/questions/27442134/git-fetch-hangs-on-git-upload-pack What sort of custom work do you have in there (branches, etc)? I'm curious to find out a way to reset this non-destructively ... and I have an idea. Li-Wen, we need to further up the timeouts here, freebsd repos are big, after all. Cheers Uli