[18:54] <antivirtel> hi, I'm using the mirror:// mirror lists on Ubuntu 22.04 server, but it seems like we have some 0 kB/s download mirror in the GB.txt: http://mirrors.ubuntu.com/GB.txt - where can I report issues related to this? - doing an apt update takes forever, kind of stuck...
[18:55] <antivirtel> (works fine on normal HTTP mirrors, like on http://gb.archive.ubuntu.com/ubuntu)
[19:29] <Fluor> antivirtel, you could report that in an e-mail to mirrors@ubuntu.com should the situation persists.
[19:31] <cmisare> antivirtel: doing a quick check against that list i'm not seeing anything glaring about not serving traffic (though my check was only against an InRelease file). if you can identify a particular mirror we should be able to remove it from that list and trigger a more thorough probe against it to try and identify issue
[19:32] <antivirtel> I just sent it in, thanks for the reply: https://rt.ubuntu.com/Ticket/Display.html?id=70317 - will do, thanks
[19:45] <antivirtel> @cmisare, I've ran it with this debug option, and it got stuck here: https://paste.ubuntu.com/p/zWR4Fg3tM4/plain/ - does it tell you where is it stuck? It doesn't tell me :( - what is the best flag to debug this with? - I see this for example in netstat: " mirrors.melbourne.co.uk:http CLOSE_WAIT  327935/http
[19:45] <antivirtel> " or " mirror-sov-a.mythic-beasts.com:http CLOSE_WAIT  327465/http" or " www.mirrorservice.org:http CLOSE_WAIT  327952/http
[19:45] <antivirtel> " but not sure if it's a problem
[21:31] <cmisare> antivirtel i think CLOSE_WAIT doesn't feel like the problem, usually that state for a socket is after data has been transferred. but from the lines in your pastebin it looks like this might be something specific to the Translations metadata from mirrors.ubuntu.com? will look at little deeper at that in a few moments
[21:48] <antivirtel> maybe I should just copy them all in directly, then try them one by one? - might take a while, but will probably tell which is the problem
[22:03] <cmisare> antivirtel, based on https://pastebin.ubuntu.com/p/zFRH8wCQHG/ i see a few mirrors that are returning bad data for some Translations files but nothing that is just hanging indefinitely for me. i'll try and follow up on the bad data cases, but can you try running the first line of my pastebin from your machine to see if it can help identify which
[22:03] <cmisare> mirror might be hanging when you try to reach them?
[22:40] <antivirtel> https://pastebin.ubuntu.com/p/99VdbGK36Z/ - it's only this: curl: (60) SSL: no alternative certificate subject name matches target host name 'mirror.xtx.cloud'
[22:40] <antivirtel> but none of them are hanging that way
[22:42] <ravage> the official ubuntu.com URLs do not offer https
[22:42] <ravage> single mirrors can. you can see supported protocols at https://launchpad.net/ubuntu/+archivemirrors
[22:43] <ravage> xtx.cloud seems to advertise https. but it is broken
[22:44] <ravage> but your sources list should no have any https sources unless you modified it manually
[22:46] <antivirtel> I'm using the "mirror://mirrors.ubuntu.com/mirrors.txt" ones, since they meant to be the quickest, and they used to be. http://mirrors.ubuntu.com/mirrors.txt -> http://mirrors.ubuntu.com/GB.txt - so it usually works fine, but sometimes this hanging forever happens
[22:47] <ravage> in my experience all mirrors usually offer enough speed
[22:48] <ravage> choose one that is hosted with like 10gbit in a big datacenter near you and you are fine
[22:49] <ravage> that lists returns the misconfigured https host
[22:50] <ravage> so maybe it would be a good idea to remove that from the list
[22:50] <ravage> and if that txt file returns https hosts there should be a check for a valid cert