Description of problem: Running dnf will typically fail to refresh expired metadata on the first run but will do so if run for a second time imediately afterwards. Version-Release number of selected component (if applicable): dnf-4.0.4-1.1.fc29.noarch How reproducible: Pretty much always since upgrading to F29. Steps to Reproduce: 1. Run and watch it not do any updates 2. Run it again and watch it magically update metadata Actual results: Run it once: % sudo dnf repoinfo compton Last metadata expiration check: 1:20:25 ago on Fri 09 Nov 2018 08:31:55 GMT. Repo-id : compton Repo-name : Fedora 29 - x86_64 - Compton Repo-status : enabled Repo-revision: 1537798242 Repo-updated : Mon 24 Sep 2018 15:10:42 BST Repo-pkgs : 86 Repo-size : 133 M Repo-baseurl : http://packages.compton.nu/fedora-29/x86_64/ Repo-expire : 300 second(s) (last: Wed 07 Nov 2018 08:13:10 GMT) Repo-filename: /etc/yum.repos.d/compton.repo Note the 300 second expiry and that the last check was over an hour ago but not new check is done. Now run it again: % sudo dnf repoinfo compton Fedora 29 - x86_64 - Compton 2.9 kB/s | 3.0 kB 00:01 Fedora 29 - x86_64 - Compton - Debug 90 kB/s | 3.0 kB 00:00 Repo-id : compton Repo-name : Fedora 29 - x86_64 - Compton Repo-status : enabled Repo-revision: 1537798242 Repo-updated : Mon 24 Sep 2018 15:10:42 BST Repo-pkgs : 86 Repo-size : 133 M Repo-baseurl : http://packages.compton.nu/fedora-29/x86_64/ Repo-expire : 300 second(s) (last: Thu 01 Jan 1970 01:00:00 BST) Repo-filename: /etc/yum.repos.d/compton.repo Suddenly we've done a refresh, but note that it now thinks the last check was at the epoch which is presumably why the next run will fail to check...
*** Bug 1648142 has been marked as a duplicate of this bug. ***
Fixed in PR https://github.com/rpm-software-management/libdnf/pull/648
*** Bug 1655610 has been marked as a duplicate of this bug. ***
Hi, I'm not sure if this is the same bug I think I'm experiencing, but if it is I guess you should give it a higher priority (new release/backporting fixes ...). Default `metadata_expire` is 7days, but after checking for updates dnf happily says (this is saved from one of dnf runs, I now always run it with `--refresh`): Last metadata expiration check: 16 days, 13:08:44 ago on Mon 17 Dec 2018 09:38:39 PM CET. Dependencies resolved. Nothing to do. Complete! And if you force it with `--refresh` it updates metadata and offers to update packages as well. I was experiencing this on multiple f29 systems.
*** Bug 1669118 has been marked as a duplicate of this bug. ***
Created attachment 1528471 [details] First nothing to do and then Waiting for process with pid 3267 to finish.
Waiting for process means, that another process has locked cache / database. It could be for example dnf-makecache.timer, another dnf process, packagekit... Please, what version of dnf are you using ($ rpm -q dnf libdnf)?
[cewijk@linux ~]$ rpm -q dnf libdnf dnf-4.0.9-2.fc29.noarch libdnf-0.22.3-1.fc29.x86_64
Created attachment 1534685 [details] Dnf upgrade session report 4
libcomps-0.1.10-2.fc29 libdnf-0.26.0-1.fc29 dnf-plugins-core-4.0.4-1.fc29 dnf-plugins-extras-4.0.2-1.fc29 dnf-4.1.0-1.fc29 librepo-1.9.4-1.fc29 createrepo_c-0.12.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810
createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1fccede810
createrepo_c-0.12.1-1.fc29, dnf-4.1.0-1.fc29, dnf-plugins-core-4.0.4-1.fc29, dnf-plugins-extras-4.0.2-1.fc29, libcomps-0.1.10-2.fc29, libdnf-0.26.0-1.fc29, librepo-1.9.4-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.