Bug 1398272

Summary: Dnf import of public keys causes stale rpmdb locks left behind
Product: [Fedora] Fedora Reporter: Panu Matilainen <pmatilai>
Component: dnfAssignee: rpm-software-management
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: igeorgex, joe, mluscon, mmraka, packaging-team-maint, pnemade, rpm-software-management, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-02 15:18:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch to fix the issue by using the same transaction set for importing none

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:09 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.