Bug 1648274 - dnf fails to refresh expired metadata
Summary: dnf fails to refresh expired metadata
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Blaha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1648142 1655610 1669118 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-09 10:05 UTC by Tom Hughes
Modified: 2019-02-21 02:56 UTC (History)
18 users (show)

Fixed In Version: dnf-4.1.0-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-21 02:56:52 UTC
Type: Bug


Attachments (Terms of Use)
First nothing to do and then Waiting for process with pid 3267 to finish. (4.30 KB, text/plain)
2019-02-09 13:58 UTC, Chrit van Ewijk
no flags Details
Dnf upgrade session report 4 (3.19 KB, text/plain)
2019-02-14 07:43 UTC, Chrit van Ewijk
no flags Details

Description Tom Hughes 2018-11-09 10:05:26 UTC
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...

Comment 1 George 2018-11-23 01:12:58 UTC
*** Bug 1648142 has been marked as a duplicate of this bug. ***

Comment 2 Marek Blaha 2018-11-29 13:24:26 UTC
Fixed in PR https://github.com/rpm-software-management/libdnf/pull/648

Comment 3 Marek Blaha 2018-12-06 11:33:42 UTC
*** Bug 1655610 has been marked as a duplicate of this bug. ***

Comment 4 Branko Grubić 2019-01-28 18:44:49 UTC
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.

Comment 5 Marek Blaha 2019-01-29 12:58:39 UTC
*** Bug 1669118 has been marked as a duplicate of this bug. ***

Comment 6 Chrit van Ewijk 2019-02-09 13:58:34 UTC
Created attachment 1528471 [details]
First nothing to do and then Waiting for process with pid 3267 to finish.

Comment 7 Marek Blaha 2019-02-11 07:17:11 UTC
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)?

Comment 8 Chrit van Ewijk 2019-02-11 15:40:37 UTC
[cewijk@linux ~]$ rpm -q dnf libdnf
dnf-4.0.9-2.fc29.noarch
libdnf-0.22.3-1.fc29.x86_64

Comment 9 Chrit van Ewijk 2019-02-14 07:43:40 UTC
Created attachment 1534685 [details]
Dnf upgrade session report 4

Comment 10 Fedora Update System 2019-02-18 10:15:19 UTC
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

Comment 11 Fedora Update System 2019-02-19 06:27:20 UTC
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

Comment 12 Fedora Update System 2019-02-21 02:56:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.