On Thu, Nov 8, 2018 at 9:31 AM Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote:
On 11/8/18 9:19 AM, Magnus Hagander wrote: > > > On Thu, Nov 8, 2018 at 9:01 AM Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: > > On 11/7/18 6:40 PM, Rémi Zara wrote: > > Hi, > > Hi Rémi! > > > > > I’m getting a lot of these errors with coypu (several per day), > but not systematically. > > Is this a problem on my end, or is this on the sever end ? > > > > Query for: stage=OK&animal=coypu&ts=1541573277 > > Target: > https://buildfarm.postgresql.org/cgi-bin/pgstatus.pl/53b137e7c765b781699bbe73e3aec7751a8c4ab7 > > Status Line: 503 Backend fetch failed > > Web txn failed with status: 1 > > Query for: stage=OK&animal=coypu&ts=1541575423 > > Target: > https://buildfarm.postgresql.org/cgi-bin/pgstatus.pl/5e8e0913dc9f9a580a4125264d74fff95f26c926 > > Status Line: 503 Backend fetch failed > > Web txn failed with status: 1 > > given the error this is something that is created by the varnish > instance that is in front of the buildfarm. On a quick look I could > immediately figure out what the problem is - but it looks like you (or > somebody else) tried at least to click one of the links above using > hist > desktop browser and got an error about a missing branch specification ;) > > > > AFAICT: > > A quick look in the logs indicates that the buildfarm is responding: > - RespHeader Status: 492 bad branch parameter > > However, 492 is not a valid http status code, so Varnish can't handle it > and thus returns 503 failure to the client.
I think that is not the actual error that Rémi is experiencing- the 492 case (which is indeed an invalid http error code) only happens when one actually klicks the link in the mail above(which I guess some did and you found in the logs) because the actual BF client will add a parameter to the "Target" URL.
The actual "errors" dont seem to show up in the lighttpd logs afaiks.
Oh, sorry. I was checking the one called "target", I assumed that was the URL that failed.
Assuming for the original ones the ts is part of the URL, none of that is still in the logs. Or are they post parameters? Do we know exactly which URL is actually failing, and when (exactly) this happened?