Kevin looked at this and saw that this server was available by rsync which was fooling the mirrormanager update code because it checks that for the quickest way to see if things are up2date.

@adrian I am not sure if there is a way we can do an additional check for other access to deal with cases like this? [It isn't the first time something like this has happened.]

Yeah, my theory is that http/https went down, but rsync was still working and it was up to date for a while before finally going out of date and getting disabled.

Perhaps the crawler could also do a quick check of http/https at the end of rsync runs? not sure how practical that will be though.

MirrorManager always does a quick check if one of the http/https URLs is working. Looking at the log I see:

2022-06-29 17:14:55,398 - WARNING - Base URL http://fastmirror.pp.ua/centos-stream/ does not exist.
2022-06-29 17:14:55,661 - WARNING - Base URL https://fastmirror.pp.ua/centos-stream/ does not exist.
2022-06-29 17:14:55,708 - INFO - Ending crawl of <Host(2828 - fastmirror.pp.ua)> with status 5

After four consecutive failures like this the host will be disabled in mirrormanager. So we have the infrastructure in place but it can take up to two days for a host being disabled. Today it seem to be disabled.

Would it be possible to add simple sanity checks (e.g. check tcp connect on HTTP, HTTPS or RSYNC ports) and remove immediately in case of failure? Simple checks could be run more aggressively as they're inexpensive .

@aneagoe it does check... 'MirrorManager always does a quick check if one of the http/https URLs is working'

So, I'm not sure what more we can do here.

Thanks for the report!