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.
Created attachment 1223793 [details] Patch to fix the issue by using the same transaction set for importing
Patch applied as commit 988a4c2fc3677743b02284245a60710236c688a1 Use the already open transaction handle for importing public keys (RhBug:1398272) Thanks.
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
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.