Red Hat Bugzilla – Bug 1019103
librepo ignores mm0:alternates
Last modified: 2014-09-30 19:41:50 EDT
Created attachment 812376 [details]
core hanging in select()
I probably have a problem with network this morning and can not connect to the fedora updates mirror. I found out that librepo will never timeout in this particular case:
URL = 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f19&arch=x86_64'
h = librepo.Handle()
h.repotype = librepo.LR_YUMREPO
h.destdir = './'
r = librepo.Result()
h.interruptible = True
h.connecttimeout = 1
if __name__ == '__main__':
Outputs when run and ^C-ed after cca 15s:
$ time ./main.py
^CTraceback (most recent call last):
File "./main.py", line 18, in <module>
File "./main.py", line 15, in main
File "/home/akozumpl/repos/librepo/build/librepo/python/python2/librepo/__init__.py", line 983, in perform
Also attaching core dump after sending another process the ABRT signal (also after some 10s).
I was able to reproduce this, but it's not a bug (or at least not on the librepo side), librepo doesn't hang, it is just trying other mirrors. For the metalink you've used it means 184 mirrors, and it takes some time.
It is all because the metalink and the mirrors are out of sync.
This is the current metalink: https://paste.fedoraproject.org/46787/
This is the current repomd.xml from the first mirror: https://paste.fedoraproject.org/46788/ (ftp://ftp.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/updates/19/x86_64/repodata/repomd.xml)
sha256sum of the repomd.xml is 90afabba594d0e1c9fa9656e6c174e8adebf099a73d39e82c9c54682f65ab6ac
But the expected one (loaded from metalink) is d4f9ad66f7c6e000d8ebf9ec92ad2c4636547853708554d93dab672bdfd98ca1
I suggest use of h.maxmirrortries option.
Or you can turn off checksum check by the
h.checksum = False
From dnf point of view, librebo should provide a better mechanism to inform about what is wrong after each mirror failure during download of metadata.
Something like LrMirrorFailureCb which is used during download of packages.
I will talk with zpavlas about this.
(In reply to Tomas Mlcoch from comment #2)
> From dnf point of view, librebo should provide a better mechanism to inform
> about what is wrong after each mirror failure during download of metadata.
> Something like LrMirrorFailureCb which is used during download of packages.
> I will talk with zpavlas about this.
(In reply to Tomas Mlcoch from comment #1)
> I was able to reproduce this, but it's not a bug (or at least not on the
> librepo side), librepo doesn't hang, it is just trying other mirrors. For
> the metalink you've used it means 184 mirrors, and it takes some time.
Thanks for clarifying, what would be the recommended value to the h.maxmirrortries option? I want a safe value which however won't let the user wait 184*timeout seconds (if I count it right) for a failure.
Also, we should probably report this to the fedora infrastructure because it is clearly not dnf/librepo's fault.
If the metalink info and mirror content's checksum don't match, that's an error in the Fedora Infra.
I will look into it.
When I run sha256sum over both the link you give (ftp://ftp.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/updates/19/x86_64/repodata/repomd.xml) or another random mirror (ftp://mirror.1000mbps.com/fedora/linux/updates/19/x86_64/repodata/repomd.xml) I get the value:
Which IS a valid checksum according to the metalink (check <mm0:alternatives>).
Could it be that you have a caching proxy that returns a stale repomd, or that the mirror you used is stale?
Okay, the summary is that librepo ignores mm0:alternates.
mm0:alternates was introduced because there's some delay between a new repomd file and the mirrors updating: we add mm:alternatives for some previous repomd revisions, so that one or two previous revisions can also be verified as correct until that mirror is synced.
Thank you for clarifying!
Fixed in head: https://github.com/Tojaj/librepo/commit/04ac52b072f3a23cf7b3177c96a23e6665e81f25
librepo-1.4.0-1.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing librepo-1.4.0-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Tested with librepo-1.4.0-1.fc20 （x86_64),seems fine,the output has been attached.
Created attachment 826466 [details]
as I could see in the traceback, it seems there was a connection problem
Are you sure, the link was working at the time when it was tested?
I turned off the network intentionally.From #comment0 :-),I think it's nessary to reproduce it
>I probably have a problem with network this morning and can not connect to the >fedora updates mirror. I found out that librepo will never timeout in this >particular case:
librepo-1.4.0-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.