Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Go packages were inaccessible from origin server on Feb 10, 2020 from 3:02~4:30 pm until 9:55 pm EST (UTC -5) #37
Hi the link (http://dmitri.shuralyov.com/gpu/mtl) is not accessible right now and is causing build issue --
Thanks for reporting.
In general, I suggest using the module mirror at https://proxy.golang.org (e.g., by setting
This particular outage should be resolved by now. See https://twitter.com/dmitshur/status/1227061882722361344 for some additional information.
I'll keep watching the server more closely to make sure it continues to be stable before closing this. Sorry for the trouble.
The root cause was a server provider hardware failure causing unavailability of the VM that was hosting the dmitri.shuralyov.com website.
Here's an annotated timeline of the outage, showing a partial graph of
I learned about the outage while at work, and realized I couldn't even SSH into the server where my site is hosted. I didn't have credentials on me to sign into the provider's portal, so I couldn't do anything until I got home. By the time I did, I saw a confirmation from the provider that it was indeed an issue on their side and they were already working on resolving it:
Based on the description (a "hardware failure") and no ETA, I wasn't confident it would be resolved soon, so I started working on setting up a second instance of the site on another server, using the data backups I had. I was doing this for the first time, so it took about 40 minutes. But the DNS TTL on the dmitri.shuralyov.com host was set to 1 hour. By the time the 1 hour was closer to done, the original VM was restored, so I just restarted my site there and reverted the DNS to point back to it.
I plan to investigate setting up either a second instance of my site running on another provider to be able to switch to in case of primary provider downtime, or a simpler static page that can point to copies of existing module versions elsewhere. I've opened issue #38 to track that.
I've also opened golang.org/issue/37175 about investigating what can or should be done in golang.org/x/exp to reduce the large number of dependencies from unrelated experimental packages.
As mentioned previously in #31 (comment), if reliability of your build is of high importance, then it's recommended to use a caching module proxy (such as the Go module mirror at https://proxy.golang.org), so that your module's build can be successful even when some origin servers are temporary unavailable. My personal website only has a 95%+ uptime SLA.
Note that as of Go 1.13, the https://proxy.golang.org module mirror is used by default without needing configuration, so this issue is most likely to affect users who haven't updated yet.