Bug 89454 - Status request for infamous rpm 4.-11 "kill-9" hang and reported 4.1-9 and 4.1.1 semi-fixes
Status request for infamous rpm 4.-11 "kill-9" hang and reported 4.1-9 and 4....
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-22 21:07 EDT by Christopher DeMarco
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-22 21:42:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher DeMarco 2003-04-22 21:07:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

Description of problem:
There are a number of bugs ( beginning with 73097, continuing in 75647, 77562,
and most recently in 83236) which describe rpm hangs/lockups.  As far as I can
tell, the specific status quo is as follows:

4.1-1.06 will hang seemingly at random, requiring a SIGKILL.  This leaves stale
locks in __db.*, which must be then deleted before trying rpm again.

4.1-9 and 4.1.1 are reported to fix the missed SIGCHLD problem, however bug
#77562 reports a "difficult to reproduce" hang in 4.1-9.  My (undocumented)
experience corraborates this.

jbj@redhat.com is quoted on www.rpm.org/errata/ as writing:

... Yes, there was a missed SIGCHLD in rpm-4.1 that "hangs" rpm. Most of the
rest of the problems I'm hearing and seeing have to do with "kill -9" and other
exceptional events. The rules have changed: ATM it's up to the user to clean up
after "kill -9". Yes, the change in rules is messy and confusing. -- Jeff
Johnson, rpm-list hosted at Red Hat, 26 Nov 2002

It is unclear to me what version of rpm (i.e. 4.1-1.0.6 || 4.1-9 || 4.1.1) is
unable to automagically cleanup its stale locks in __db.*  

#75647 is largely unremarkable except for the closing remark by jbj@redhat.com
that there's "Errata coming".  I don't see anything in the RH8 Errata about this
issue.  Hence the basis for my bugreport.

What, please, is the current status quo (documented or otherwise) regarding this?  

<sob story> I need to be able to trust that an automated, unattended,
unsupervised rpm install will reliably exit with SOME status (error||success);
manually detecting and cleaning-up-after an rpm hang is unacceptable in my
situation. </sob story>

I'd very much like to see the Errata which jbj@redhat.com referred to as
"forthcoming" and a clarification of what the current status of this "hanging
rpm/lock cleanup" issue is in the current (4.1-9 && 4.1.1) versions of rpm. 
Especially considering the proliferation of multiple-issue bug reports, a clear
statement of the situation would be very very helpful.

Version-Release number of selected component (if applicable):
4.1-9, 4.1.1

How reproducible:
Sometimes

Steps to Reproduce:
1.  Google web and newsgroups for any of "rpm 4.1-0.6 4.1-9 4.1.1 hang SIGCHLD"
2.  search bugzilla.redhat.com for similar terms
3.  search rpm.org, redhat.com for similar terms

Actual Results:  Head starts to hurt, version numbers become impossible to
differentiate, automated rpm installs still behave unpredictably, current 
state-of-affairs still muddy.

Additional info:
Comment 1 Christopher DeMarco 2003-04-22 21:09:56 EDT
Oh yeah - thanks to jbj@redhat.com for dealing with the avalanche of bug reports
about this issue.  Hopefully my re-opening it doesn't impact your quality of
life too severely.
Comment 2 Jeff Johnson 2003-04-22 21:42:09 EDT
If you are running kernel-2.4.18 (Red Hat 8.0), you want
    rpm-4.1.1-1

If kernel-2.4.20 (with NPTL/TLS, Red Hat 9) you want
    rpm-4.2-1

Errata pending, bits currently at
    ftp://ftp.rpm.org/pub/rpm/test-{4,2,4.1.1}

If other problems, reopen this bug.

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