Bug 153722

Summary: rpm hang on up2date with futex
Product: [Fedora] Fedora Reporter: Telsa Gwynne <hobbit>
Component: rpmAssignee: Paul Nasrat <nobody+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   
Whiteboard:
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:
Embargoed:
Attachments:
Description Flags
script with output of ps aux, strace and gdb
none
/var/log/rpmpkgs
none
/root/install.log
none
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):
rpm-4.4.1

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]
/var/log/rpmpkgs
Comment 4 Telsa Gwynne 2005-04-05 13:57:30 UTC 
Created attachment 112715 [details]
/root/install.log
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)