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 153722

Summary: rpm hang on up2date with futex
Product: [Fedora] Fedora Reporter: Telsa Gwynne <hobbit>
Component: rpmAssignee: Paul Nasrat <pnasrat>
Status: CLOSED WORKSFORME QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: davej, juanino, n3npq
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-04 15:06:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
script with output of ps aux, strace and gdb
The rpm --qf one. none

Description Telsa Gwynne 2005-04-05 10:34:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

Description of problem:

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

How reproducible:
Didn't try

Steps to Reproduce:
1. Install fc4test1 
2. up2date -u --nosig (do this as text not as gui version)
That was it. :( 

Actual Results:  After some time, up2date just sat there... 

[409] xorg-x11-twm 
##### 100%
[410] yum
##### 100%

..and sat there. 

top revealed nothing useful (other than a gdm-binary process munching CPU)
strace said
futex(0x1460c44, FUTEX_WAIT, 1, NULL <unfinished>
gdb said nothing helpful. 

In the end, I did ^C on it and re-ran up2date. It now thinks
that it is up to date and that it needs download nothing more.
Despite rpm --rebuilddb though, I seem to have two copies of
most rpms on the machine.  

Additional info:

cc'ing because I got told to :) 

script attached with more useful output.

Comment 1 Telsa Gwynne 2005-04-05 10:38:15 UTC
Created attachment 112711 [details]
script with output of ps aux, strace and gdb

Comment 2 Paul Nasrat 2005-04-05 12:11:52 UTC
Could you attach /var/log/rpmpkgs /root/install.log and the output of 

rpm --qf '%{name}-%{version}.%}release}.%{arch}\n' -qa

Comment 3 Telsa Gwynne 2005-04-05 13:55:46 UTC
Created attachment 112714 [details]

Comment 4 Telsa Gwynne 2005-04-05 13:57:30 UTC
Created attachment 112715 [details]

Comment 5 Telsa Gwynne 2005-04-05 14:00:10 UTC
Created attachment 112716 [details]
The rpm --qf one.

Comment 6 Jerry Uanino 2005-07-06 14:35:22 UTC
I experienced an rpm hang on u2pdate, when stracing it was sitting on futex as 
well.  This is on:

Red Hat Enterprise Linux AS release 3 (Taroon Update 5)

more specifically, it was after doing an update -u from update 2 (I believe).  
I rebooted after up2date -u and rpm -qa would hang, and up2date would hang as 
well.  This was corrected with a reboot, but sounds similar to this problem so 
I thought I would log a comment in here.

Comment 7 Jeff Johnson 2005-10-31 16:34:39 UTC
This is likely to be a stale lock and non-reproducible.

Display stale locks by doing
    cd /var/lib/rpm
    /usr/lib/rpm/rpmdb_stat -CA
The normal quiescent (i.e. rpm not running) state is no locks.

Fix stale locks by doing
    rm -f /var/lib/rpm/__db*

Comment 9 Jeff Johnson 2005-11-04 12:35:05 UTC
Why is this bug reopened without additional information?

Comment 10 Chris Kloiber 2005-11-04 15:06:44 UTC
This issue was attached to a Red Hat Global support ticket. But you are correct
it shouldn't be as this was against FC4-test1.

Comment 11 Jerry Uanino 2005-11-04 15:50:37 UTC
It also happens to me on:
Red Hat Enterprise Linux AS release 3 (Taroon Update 5)