Bug 90931 - silent rpm query failures during rebuilddb
Summary: silent rpm query failures during rebuilddb
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-15 14:25 UTC by Lee Killough
Modified: 2007-04-18 16:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-25 03:30:38 UTC
Embargoed:


Attachments (Terms of Use)

Description Lee Killough 2003-05-15 14:25:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021203

Description of problem:
After upgrading to 4.2-1 to "fix" some hangs, rpm is unusable, and
the database is always empty.

rpm -q -a returns nothing

rpmdb -vv --rebuilddb rebuilds the database with a lot of messages such as:

D:  read h#     232 Header V3 DSA signature: OK, key ID db42a60e
D:   +++ h#      29 Header V3 DSA signature: OK, key ID db42a60e
D: adding "redhat-config-soundcard" to Name index.
D: adding 34 entries to Basenames index.
D: adding "System Environment/Base" to Group index.
D: adding 11 entries to Requirename index.
D: adding 2 entries to Providename index.
D: adding 28 entries to Dirnames index.
D: adding 11 entries to Requireversion index.
D: adding 2 entries to Provideversion index.
D: adding 1 entries to Installtid index.
D: adding 1 entries to Sigmd5 index.
D: adding "e6716e25fba5d06c6fc920ff2754468ab5d09491" to Sha1header index.
D: adding 34 entries to Filemd5s index.


However, after it is finished, rpm is still useless, as rpm -q -a returns nothing.

rpm -q rpm returns immediately and prints nothing.

__db* files still remain even though I removed them after the rpm upgrade and
before the rebuild.


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

4.2-1

How reproducible:
Always

Steps to Reproduce:
1. rm -f /var/lib/rpm/__db*
2. rpmdb -vv --rebuilddb
3. rpm -q -a
    

Actual Results:  rpm -q -a returns nothing

Expected Results:  database should be intact


Additional info:

Comment 1 Lee Killough 2003-05-15 15:56:31 UTC
rebuilddb seems to run partially in the background, and only finishes after 30
minutes or more.

rpm -q -a works fine after 30 minutes.

A less silent behavior, such as a warning from the rebuilddb that it will be
backgrounded and take a while, or an error from the query indicating a rebuild
is currently in progress (and possibly that a lock cannot be obtained), would be
helpful.

This explains the lockfiles being left around in /var/lib/rpm, because the
rebuild was still going on. However, it doesn't explain the empty query results.

Could this be a problem with the rpm hang fix being too relaxed with respect to
locks? Are queries no longer blocked by rebuilds, and do they simply return no
data?


Comment 2 Barry K. Nathan 2003-05-16 08:49:50 UTC
I'm also seeing cases where rpm -q returns no output (specifically, bug 89736).

Comment 3 Jeff Johnson 2003-05-22 00:18:39 UTC
Hmmm, hard to say whether this is a locking issue or
something else.

If locking, then executing
    cd /var/lib/rpm
    /usr/lib/rpm/rpmdb_stat -CA
displays all locks. There should be no locks displayed
in normal quiescent behavior.

Note that the __db* files are persistent, and contain locks,
but are not the locks themselves.

FWIW, --rebuilddb should complete in less than 10 minutes, add -vv
to watch progress.

So, given the above information, what sort of problem do you have?
Locking or something else?

Comment 4 Lee Killough 2003-06-25 03:30:38 UTC
Problem has not been seen since original occurrence.

Rebuild took longer than expected (over 30 minutes -- this is an "Everything"
installation), but during the rebuild rpm -q and other rpm commands returned
nothing, while ideally they should have reported a failure to obtain a lock
while the rebuild was still going on. I'd still make sure locks are being
handled properly.

Closing it out for now.



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