Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1515329 - rpm command hangs time by time
Summary: rpm command hangs time by time
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libdb
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Petr Kubat
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2017-11-20 15:20 UTC by Jiri Vavra
Modified: 2019-03-29 07:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description Jiri Vavra 2017-11-20 15:20:23 UTC
Description of problem:
Time by time it happens, that rpm command doesn't finish and is stuck with FUTEX_WAIT

# strace -p 3691
Process 3691 attached
futex(0x7f9d5fbde37c, FUTEX_WAIT, 18, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x7f9d5fbde37c, FUTEX_WAIT, 19, NULL

The cause it because of lock files /var/lib/rpm/__db.00*

This behavior is well and long-time known. More information in e.g.

It can cause more troubles than unavailability of rpm, yum and sosreport commands - based on following ticket it causes "docker version/info become non-responsive"

Therefore, solving the root cause of the hang (deadlock) could help other components too.

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

How reproducible:

Steps to Reproduce:

Actual results:
rpm hangs

Expected results:
rpm doesn't hang

Additional info:

Comment 3 Petr Kubat 2018-11-06 07:51:40 UTC
This looks like an issue with stale mutexes from a previous access of the libdb environment used by rpm. The workaround is removing the mmaped environment files (/var/lib/rpm/__db*) as correctly explained by the solution doc.

Unfortunately without a way to reproduce the hang it would be very hard to find the spot where the the mutex is left locked. Will leave the bug open in case we run into it again with some reproduced at hand.

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