guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsi


From: Chris Marusich
Subject: Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
Date: Thu, 21 Feb 2019 19:41:41 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Giovanni Biscuolo <address@hidden> writes:

> $ guix weather --manifest=.ungoogled-chromium.manifest
> computing 1 package derivations for x86_64-linux...
> looking for 1 store items on https://ci.guix.info...
> https://ci.guix.info
>   100.0% substitutes available (1 out of 1)
>   99,3 MiB of nars (compressed)
>   288,3 MiB on disk (uncompressed)
>   0,004 seconds per request (0,0 seconds in total)
>   262,4 requests per second
>   'https://ci.guix.info/api/queue?nr=1000' returned 504 ("Gateway Time-out")
>
> actually all https://ci.guix.info/ returns 504 "Gateway Time-out":
> AFAIU this mean I'm not able to install that package (possibly others)
> for some problem in the CDN

Summary: A Cuirass API is failing, but substitutes are available.  The
CDN is not the problem.  I'll explain more below.

The 504 error comes from berlin, not the CDN.  If you access
berlin.guixsd.org directly when the 504 occurs, I think you'll see a 504
from there, too.  The CDN is merely forwarding you the 504 it got from
berlin.  I've observed this behavior multiple times in the past.  The
next time this happens, try viewing the offending location via berlin
directly in your browser:

https://berlin.guixsd.org/api/queue?nr=1000

I think you'll find that berlin, not the CDN, returns the 504 error.  To
understand why berlin.guixsd.org returns a 504, we would need someone to
investigate more on the server side.  I don't know if anyone understands
why this happens; I don't have access to investigate berlin, myself.

In any case, the 504 for the /api/queue path doesn't imply that
substitutes are unavailable.  Indeed, your "guix weather" output states
that the 1 substitute you were looking for was in fact available.  How
can this be?  Well, both Cuirass and "guix publish" are served through a
front-end NGINX web server, which confuses matters a little.  The name
berlin.guixsd.org resolves to that NGINX web server.  That NGINX web
server forwards requests to their appropriate destination ("guix
publish" or Cuirass) depending on the path.  Substitutes are served from
"guix publish" via one set of paths (e.g., /nar/gzip/<store-item>), and
Cuirass resources are served from Cuirass via a different set of paths
(e.g., "/api/queue").  It's possible for a Cuirass path to fail even
though the "guix publish" paths are working just fine.  This is because
"guix publish" and Cuirass are not the same thing, even though they are
served via the same domain name.

What I'm trying to say is that the 504 doesn't mean substitutes are
unavailable.  However, it does suggest a problem with Cuirass or its
dependencies.  When you run commands that fetch substitutes, like "guix
build" and "guix install," you will probably find that the substitution
is not failing.  If that isn't the case, please let us know.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]