[solved] mirror.mijn.host is unreliable despite rankmirrors (always)

probackup-nl · 2025-07-23 09:08:40

Updating using -Syu is always preceeded with "rankmirrors -vn 5 -m 0.1" command to disable slow hosts.

Despite that for at least 5 and I think even last 10 updates, the resulting output contains:
error: failed retrieving file 'xy' from mirror.mijn.host : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds
error: failed retrieving file 'yz' from mirror.mijn.host : Connection timed out after 10002 milliseconds

Resulting in "warning: too many errors from mirror.mijn.host, skipping for the remainder of this transaction".

This always happens from an IP in network AS201290, but not in another AS.

Is anyone else in The Netherlands experiencing this issue?

Last edited by probackup-nl (2025-08-19 09:41:38)

seth · 2025-07-23 15:29:43

After https://mirror.mijn.host/ originally opened immediately and I could browse to https://mirror.mijn.host/archlinux/core/os/x86_64/ no problem, now I cannot download https://mirror.mijn.host/archlinux/core … .db.tar.gz from browser nor

curl -vL 'https://mirror.mijn.host/archlinux/core/os/x86_64/core.db.gz' > /dev/null

There's probably some weird quota going on - and it's not limited to Goudaland

mijn.host · 2025-07-24 15:08:29

Thank you for notifying!
We did some rate limiting, but we now have changed the settings. Please check again.

seth · 2025-07-24 19:09:03

Works for me (slightly east of Frau-Antje-Land)

probackup-nl · 2025-07-27 07:32:19

1.) Try #1 = OK: no error. I checked that mirror.mijn.host is the first entry in mirrorlist (with lowest 0.042428 second latency).

linux-6.15.8.arch1-1-x86_64 141.2 MiB 101 MiB/s 00:01 [####################################] 100%
glibc-2.41+r65+ge7c419a29575-1-... 10.0 MiB 90.7 MiB/s 00:00 [####################################] 100%
lib32-glibc-2.41+r65+ge7c419a29... 3.4 MiB 35.6 MiB/s 00:00 [####################################] 100%
bash-5.3.3-1-x86_64 1932.3 KiB 27.7 MiB/s 00:00 [####################################] 100%
lib32-libx11-1.8.12-2-x86_64 622.3 KiB 24.3 MiB/s 00:00 [####################################] 100%
Total (5/5) 157.1 MiB 87.2 MiB/s 00:02 [####################################] 100%

2.) Second network: latency for mijn.host is lowest again with 0.115428 seconds.

However the downloads are sometimes sloooow and rate is varying, and averaging at: 176 KiB/s instead of expected 10 MiB/s.

3.) A third try from the same network as used in try number one is not giving errors. Stable and steady fast download rates are missing:
linux-6.15.8.arch1-1-x86_64 141.2 MiB 58.2 MiB/s 00:02 [####################################] 100%
perl-5.42.0-1-x86_64 20.4 MiB 2.64 MiB/s 00:08 [####################################] 100%
glibc-2.41+r65+ge7c419a29575-1-... 10.0 MiB 24.3 MiB/s 00:00 [####################################] 100%
gettext-0.26-1-x86_64 2.8 MiB 1414 KiB/s 00:02 [####################################] 100%
sqlite-3.50.3-1-x86_64 2.2 MiB 1491 KiB/s 00:02 [####################################] 100%
bash-5.3.3-1-x86_64 1932.3 KiB 59.0 MiB/s 00:00 [####################################] 100%

I can't mark this as solved (yet). With this performance I'd rather see mijn.host excluded from the mirrorlist.

Last edited by probackup-nl (2025-07-27 08:01:49)

V1del · 2025-07-27 15:17:55

? What's stopping you from dropping it from your mirror list if it doesn't work well for your case? If you're unlucky this could also be down to just your specific provider.

probackup-nl · 2025-07-29 11:36:57

An example command how to exclude a specific host, at the rankmirrors wiki page, near section 3.1.2 "Fetching and ranking a live mirror list", is stopping me from dropping mijn.host.

WorMzy · 2025-07-29 12:50:56

It's a text file. Either edit it directly, or if you must use rankmirrors for whatever reason, pipe it through grep -v.

probackup-nl · 2025-08-01 11:16:21

The wiki example already uses the sed command. According to man, sed is for filtering and transforming text. That way I prefer to use sed and not introduce a new command.

With some trial and error, suffixing the sed command with this ugly part seems to do the job:

 -e '/^#/d' -e 's/.*mirror\.mijn\.host.*//;/^$/d'

Luckily later on I figured out that

 -e '/mirror.mijn.host/d'

brings the same result: excluding one specific host before running rankmirrors.

BTW Currently I can't test whether mijn.host issue is solved, because the host is unreachable.

Last edited by probackup-nl (2025-08-01 11:41:59)

seth · 2025-08-01 12:46:26

" -e '/^#/d'" removes lines that start w/ a comment
"/^$/d" matches empty lines
The relevant "ugly" part is ".*mirror\.mijn\.host.*" which, just as "'/mirror.mijn.host/d'" will match more than you think - "." matches *every* character, you've to escape "\." if you literally want to match a dot.

Try

-e '/^#/d; /^$/d; /mirror\.mijn\.host/d'

probackup-nl · 2025-08-19 09:40:49

@mijn.host The "Connection timed out " issue for mirror.mijn.host seems to be solved, at least at this moment.

Arch Linux

#1 2025-07-23 09:08:40

[solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#2 2025-07-23 15:29:43

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#3 2025-07-24 15:08:29

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#4 2025-07-24 19:09:03

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#5 2025-07-27 07:32:19

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#6 2025-07-27 15:17:55

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#7 2025-07-29 11:36:57

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#8 2025-07-29 12:50:56

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#9 2025-08-01 11:16:21

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#10 2025-08-01 12:46:26

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

#11 2025-08-19 09:40:49

Re: [solved] mirror.mijn.host is unreliable despite rankmirrors (always)

Board footer