Bug 153722 - rpm hang on up2date with futex
rpm hang on up2date with futex
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-05 06:34 EDT by Telsa Gwynne
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-04 10:06:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
script with output of ps aux, strace and gdb (8.96 KB, text/plain)
2005-04-05 06:38 EDT, Telsa Gwynne
no flags Details
/var/log/rpmpkgs (24.30 KB, text/plain)
2005-04-05 09:55 EDT, Telsa Gwynne
no flags Details
/root/install.log (71.96 KB, text/plain)
2005-04-05 09:57 EDT, Telsa Gwynne
no flags Details
The rpm --qf one. (27.71 KB, text/plain)
2005-04-05 10:00 EDT, Telsa Gwynne
no flags Details

  None (edit)
Description Telsa Gwynne 2005-04-05 06:34:49 EDT
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 06:38:15 EDT
Created attachment 112711 [details]
script with output of ps aux, strace and gdb
Comment 2 Paul Nasrat 2005-04-05 08:11:52 EDT
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 09:55:46 EDT
Created attachment 112714 [details]
/var/log/rpmpkgs
Comment 4 Telsa Gwynne 2005-04-05 09:57:30 EDT
Created attachment 112715 [details]
/root/install.log
Comment 5 Telsa Gwynne 2005-04-05 10:00:10 EDT
Created attachment 112716 [details]
The rpm --qf one.
Comment 6 Jerry Uanino 2005-07-06 10:35:22 EDT
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 11:34:39 EST
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 07:35:05 EST
Why is this bug reopened without additional information?
Comment 10 Chris Kloiber 2005-11-04 10:06:44 EST
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 10:50:37 EST
It also happens to me on:
Red Hat Enterprise Linux AS release 3 (Taroon Update 5)

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