Timeout on mirrors.fedoraproject.org


I’ve configured automatic yum updates on many machines, nearly all of them are frequently (almost every night) receiving a timeout error from “mirrors.fedoraproject.org” for the EPEL repo. The exact error is:


Could not get metalink
https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64&infra=st[..] error was
12: Timeout on
https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64&infra=st[..] (28,
'Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds')

Machines are a mix of Centos 6, 7, and 8. Mostly CentOS 7 and 8; this error happens to be from an EL7 machine; but all of them are doing it.

If I manually run these commands, they’re successful. I suspect this is load on the mirror network during overnight updates; but I can’t definitively say so.

Is there a way that I can confirm this is simply mirror network load?
If this is mirror network load, what is the best practice for scheduling my updates to help distribute load better for the mirror network?

Is this recent behaviour of your system? Could be related to https://lists.fedoraproject.org/archives/list/announce@lists.fedoraproject.org/thread/L3MAYSUM52C4G6PFVDZ6SEFKHCHGUUZS/?

Let us know if problem persists in a week from now.

Mirror Manager and mirror list seem to work fine: https://status.fedoraproject.org/

Maybe it’s a problem with the mirror you are connecting too (if it is the same every time).

There is always night somewhere on earth… :earth_asia:
What I mean: I don’t think so.

It’s been happening for a couple of months at least, some nights more than others; and definitely more recently. I will wait as suggested and update here if the issue is still occurring.

Thank you for taking the time to respond.

If it’s happening since a couple of months, it is certainly not related to the move of the Mirror manager or the Mirror list servers.

Are your servers always trying to connect to the same mirror by any chance?

Did you try scheduling the cron job an hour earlier or and hour later? Does that make a difference?

Do you have a fastestmirror=True in your dnf.conf (or yum)?

The epel.repo file (installed via “yum install epel-release”) specifies a metalink, for example on this CentOS7 machine:

name=Extra Packages for Enterprise Linux 7 - $basearch

The error received indicates that this URL times out.

The default configuration, which I’m using, places the cron job at /etc/cron.hourly/0yum-hourly.cron

As such, it should be running hourly (not daily). The errors only occur in the overnight hours in UCT-5/CST.

The /etc/yum/yum-cron-hourly.conf file is not configured to download updates, updates happen in 0yum-daily.cron which calls /etc/yum/yum-cron.conf. Interestingly, I have not received an error from 0yum-daily.cron at all - only from 0yum-hourly.cron.

I sampled CentOS 6, 7, and 8 machines and did not see fastestmirror=True in any of them.

I’ll try installing that module to see if it helps.

Thank you for taking the time to reply, I appreciate it.

Thanks for taking the time to reply @florian, I’ve taken another path - probably a better path. I’ve set up an even faster mirror on my LAN, since I already had a local CentOS mirror it just made more sense to take that load off the mirror network by moving my ~70 machines to a LAN mirror for EPEL. The documentation I was able to easily find throughout fedoraproject.org made the process quite simple.

1 Like

I have had that error on and off on every centos or fedora system I’ve had for years.

Should fastestmirror be set to True or False for the most resilient operation? (not erroring out in the middle of the night)

One of mine was acting up for 3 hours last night. It was set to True and I just tried setting it to false. Won’t know for a few months if it had any affect. Never actually will, since I can’t predict when the mirrors are going to time out.

This thread has been idle for over 2 years. You really should start a new thread for your concerns.

That said, often it is seen that many updates seem to be run at nearly the same time and a simple change to the timing of your updates will often reduce or eliminate the timeouts since it accesses the servers at a different time and with them at a different load level.