Hello Steven,
Steven Holden wrote:
> Imagine my dismay on making a software request directing the team to look to
> the page
> Binary Installation (GNU Guix Reference
> Manual)<https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>
> Where the binary install script is accessed by wget at
> https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
Wow! They are actually using that path in their installation as a
documented process? I never would have thought it! I would have
expected to see that in the release area where it could be distributed
through the download mirror pool. Then it would have a pool of
servers to distribute the load around. Relying upon the one single
upstream system for global distribution is going to be both a
bottleneck and also a reliability issue. Single source can't be
highly available. And it is very hard on that single upstream server!
Use a mirror if possible.
The reason I am rather shocked is that the cgit web browse interface
to the git repositories is a dynamic CGI script. It's just going to
do the best it can to present files in a web browsable way from the
git repositories. And it is sometimes overloaded with waves of abuse
from the hostile Internet. Needing to dynamically create the
rendering it is always going to be slower than just sending files.
And it is sometimes buggy. It's not the place I would have thought
anyone would use for a global install location.
This really feels like an xkcd moment.
https://xkcd.com/2347/
> and the link is broken.
> In fact
> https://git.savannah.gnu.org/cgit
> is also broken
It's a bug in cgit. I have been trying to debug that problem for the
last week! It just started misbehaving one day. There was a report a
month ago and then it disappeared and we couldn't reproduce it. I
thought it must have been a bad proxy in the middle because I have
experienced those before. Then it started to come and go. Then just
recently it has been locked hard in to the failing mode. Which is
good if it allows debugging. I have been stepping through the code in
the debugger for the past two days. There is some bug in the cache
handling routine. I haven't gotten to the root cause of the bug yet.
In the process of debugging this the layers of caching was of course
getting in the way of the problem. I turned caching off. And then
discovered that cgit works if the cache is disabled! In that case the
rendering functions always renders the correct result. And so now we
are running with caching disabled.
Of course caching is there to improve performance. But by my feeling
for things it feels snappier and more responsive with the caching off.
Therefore the system must be bound by I/O more than CPU.
> even if I navigate to
> https://git.savannah.gnu.org/
> and click cgit or enter it manually.
If you enter the project manually then it always works. For example
for coreutils if you directly enter the URL then it always works.
https://git.savannah.gnu.org/cgit/coreutils.git/
Even with caching enabled entering the full URL such as the above
always gave back the correct results. I think because the total
amount of data for it is contained and smaller. But the full index
page is quite large. That's one of the differences.
> Thanks for looking into this before the software assessment team
> sees it! I really hope to get Guix approved here.
We have been talking about the cgit problem for the past week. I am
sure by now that the Guix folks will be aware of the problems with it.
If you are not subscribed to the savannah-users mailing list then I
suggest it would be a good thing. It is a low volume list.
But now having discovered the problem can be mitigated by disabling
the cache we also have caching turned off now too. I am still
continuing to work through the source to try to figure out where it
goes wrong.
And it is also super weird because EVERYONE pretty much all runs cgit
for browsing git repositories. I am running it on other servers. Why
is it only this one situation where it has this bug? No idea. But
since it is only a problem here that pretty much means it is up to us
to debug it here. The link mangling problem when served from cache
must be an atypical combination of things.
Thank you for sending in your problem report! It's always good to
communicate about things.
Bob
