Bug 88788

Summary:	rpm --rebuilddb fails
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <md_dr_x>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED WORKSFORME	QA Contact:	Mike McLean <mikem>
Severity:	high	Docs Contact:
Priority:	medium
Version:	9	CC:	ak
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-04-14 14:41:37 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:

Description Need Real Name 2003-04-14 06:19:59 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
whenever I run rpm --rebilddb I get this error

error: db4 error(16) from dbenv->remove: Device or resource busy

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

How reproducible:
Always

Steps to Reproduce:
1.in a shell I type rpm --rebuilddb    

Actual Results:  the output before it crashes:

D: adding "Development/Languages" to Group index.
D: adding 13 entries to Requirename index.
D: adding 3 entries to Providename index.
D: adding 3 entries to Dirnames index.
D: adding 13 entries to Requireversion index.
D: adding 3 entries to Provideversion index.
D: adding 1 entries to Installtid index.
D: adding 1 entries to Sigmd5 index.
D: adding "665ca8b6dab16505c57ffe91c661dec74bc7d4f5" to Sha1header index.
D: adding 53 entries to Filemd5s index.
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
error: db4 error(16) from dbenv->remove: Device or resource busy
D: removed  db environment /var/lib/rpm/Packages
D: closed   db index       /var/lib/rpmrebuilddb.4659/Pubkeys
D: closed   db index       /var/lib/rpmrebuilddb.4659/Filemd5s
D: closed   db index       /var/lib/rpmrebuilddb.4659/Sha1header
D: closed   db index       /var/lib/rpmrebuilddb.4659/Sigmd5
D: closed   db index       /var/lib/rpmrebuilddb.4659/Installtid
D: closed   db index       /var/lib/rpmrebuilddb.4659/Provideversion
D: closed   db index       /var/lib/rpmrebuilddb.4659/Requireversion
D: closed   db index       /var/lib/rpmrebuilddb.4659/Dirnames
D: closed   db index       /var/lib/rpmrebuilddb.4659/Triggername
D: closed   db index       /var/lib/rpmrebuilddb.4659/Conflictname
D: closed   db index       /var/lib/rpmrebuilddb.4659/Providename
D: closed   db index       /var/lib/rpmrebuilddb.4659/Requirename
D: closed   db index       /var/lib/rpmrebuilddb.4659/Group
D: closed   db index       /var/lib/rpmrebuilddb.4659/Basenames
D: closed   db index       /var/lib/rpmrebuilddb.4659/Name
D: closed   db index       /var/lib/rpmrebuilddb.4659/Packages
D: closed   db environment /var/lib/rpmrebuilddb.4659/Packages
D: removed  db environment /var/lib/rpmrebuilddb.4659/Packages
D: removing directory /var/lib/rpmrebuilddb.4659
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
[root@Andrew root]# 

Expected Results:  no output

Additional info:

I had installed some alsa rpm's beforehand from freshrpms.net.

Comment 1 Jeff Johnson 2003-04-14 14:41:37 UTC

Yes, an attempt to remove the dbenv while still in
use prints an error message. The message is harmless.

Comment 2 Alex Kanavin 2003-04-14 16:38:50 UTC

It is harmless to the existing database, 
but rpm does not actually create a new rebuilt 
database either and it leaves __db* files in 
/var/lib/rpm. Upgrading to rpm-4.2-1 does not help.

Comment 3 Jeff Johnson 2003-04-14 16:43:06 UTC

Say what? The above -vv snippet shows that the indices were
sucessfully rebuilt, and renamed back into place, in spite
of the error.

Yes __db* files are persistent in rpm-4.1 and later.

Upgrading to rpm-4.2 does not help *what*?

Comment 4 Alex Kanavin 2003-04-14 17:03:44 UTC

Maybe I was confused by the fact that the mtime of the indices
stays exactly the same as before after the rebuild. 
Is that how it should be?

Comment 5 Jeff Johnson 2003-04-14 17:04:51 UTC

Yes. Try looking at the creation time.

Comment 6 Alex Kanavin 2003-04-14 17:21:42 UTC

Creation time? Unix files do not have that, I always thought.

The glibc manual says:
==============
Each file has three time stamps associated with it:  its access time,
its modification time, and its attribute modification time. [...]
When a file is created, all three time
stamps for that file are set to the current time.
==============
So how do the mtimes of the new indices end up being set 
to the mtimes of the old ones I don't understand....
But the inode numbers change, so it must be working indeed.

Comment 7 Jeff Johnson 2003-04-14 18:11:30 UTC

Yup, no create time, I'm corrected.

Yes, I forgot inode, and meant the time that can't
be changed with utime(2) or utimes(2).

But we agree files are changed ;-)