Bug 90931
| Summary: | silent rpm query failures during rebuilddb | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Lee Killough <redhat> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WORKSFORME | QA Contact: | Mike McLean <mikem> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | barryn, p.van.egdom, redhat |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-06-25 03:30:38 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: | |||
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? I'm also seeing cases where rpm -q returns no output (specifically, bug 89736). 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?
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. |
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: