Bug 1398272 - Dnf import of public keys causes stale rpmdb locks left behind
Summary: Dnf import of public keys causes stale rpmdb locks left behind
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-24 11:24 UTC by Panu Matilainen
Modified: 2017-02-02 05:27 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-12-02 15:18:12 UTC


Attachments (Terms of Use)
Patch to fix the issue by using the same transaction set for importing (1.69 KB, patch)
2016-11-24 11:29 UTC, Panu Matilainen
no flags Details | Diff

Description Panu Matilainen 2016-11-24 11:24:27 UTC
Description of problem:

The way dnf implements import of public keys causes stale locks on rpmdb to left behind, causing tonne of "Freeing read locks..." warnings on next rpm invocation.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. dnf -y --releasever=24 --installroot=/srv/test/ install bash
2. rpm --root /srv/test/ -q bash

Actual results:
root@sopuli rpm]# rpm --root /srv/test/ -q bash
warning: rpmdb: BDB2053 Freeing read locks for locker 0x1: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x3: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x4: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x5: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x6: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x7: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x8: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0x9: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0xa: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0xb: 29302/140041382455040
warning: rpmdb: BDB2053 Freeing read locks for locker 0xc: 29302/140041382455040
[...]
bash-4.3.42-7.fc24.x86_64

Expected results:
No warnings emitted from normal operation.

Additional info:

This is caused by the ts handles here, ts handles there, ts handles everywhere madness dnf unfortunately inherited from yum. When the key import happens dnf already has a handle open on rpmdb but the code opens another "readonly" handle for import purposes for who knows what reason. 

This happens on both dnf 1.1 and 2.0 AFAICS.

Mind you, quite possibly there's an rpm bug involved too. But nevertheless two different handles on the same rpmdb are not a good idea, even less so when there's absolutely no reason to do so.

Comment 1 Panu Matilainen 2016-11-24 11:29 UTC
Created attachment 1223793 [details]
Patch to fix the issue by using the same transaction set for importing

Comment 2 Michael Mráka 2016-11-25 12:52:22 UTC
Patch applied as
commit 988a4c2fc3677743b02284245a60710236c688a1
    Use the already open transaction handle for importing public keys (RhBug:1398272)


Thanks.

Comment 3 Joe Doss 2017-02-02 05:19:27 UTC
This is still happening in Fedora 25

TASK [elasticsearch : Import Elasticsearch RPM GPG key] ************************
fatal: [dev]: FAILED! => {"changed": false, "failed": true, "msg": "rpm returned unexpected output [BDB2053 Freeing read locks for locker 0x189: 11740/140270815971072]"}

[vagrant@dev ~]$ dnf --version
1.1.10
  Installed: dnf-0:1.1.10-5.fc25.noarch at 2017-02-02 04:46
  Built    : Fedora Project at 2017-01-17 16:20

  Installed: rpm-0:4.13.0-6.fc25.x86_64 at 2017-02-02 04:49
  Built    : Fedora Project at 2016-12-03 12:31

Comment 4 Joe Doss 2017-02-02 05:27:47 UTC
I will also note that this happens every time after installing packages via shell and through Ansible's dnf module. Importing a GPG key after those steps will always result in this error.


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