Bug 1398272 - Dnf import of public keys causes stale rpmdb locks left behind
Dnf import of public keys causes stale rpmdb locks left behind
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-24 06:24 EST by Panu Matilainen
Modified: 2017-02-02 00:27 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-02 10:18:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Panu Matilainen 2016-11-24 06:24:27 EST
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 06:29 EST
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 07:52:22 EST
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 00:19:27 EST
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 00:27:47 EST
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.