RPM Community Forums

Mailing List Message of <rpm-users>

Re: About the consistency of /var/lib/rpm/__db.00?

From: Marc MERLIN <marc_rpm@merlins.org>
Date: Tue 25 May 2010 - 19:23:08 CEST
Message-ID: <20100525172308.GL6064@merlins.org>
On Tue, May 25, 2010 at 01:09:12PM -0400, Jeff Johnson wrote:
> >>> Nope. There are (at least) 3 RPM user visible uses of __db* files, none of them
> >>> "temporary" or "index":
> >>> 	1) a version stamp
> >>> 	2) names of locks (and with thread_count, "stale lock" registration
> >>> 	for clean-up after exceptional conditions like reboot and segfault
> >>> 	and programmer error). Note "names", not the locks themselves.
> >>> 	3) data caching
> > 
> > Ok, I'm working on this some more because this _db* files really need to die
> > for us.
> There's always
> 	rm -f /var/lib/rpm/__db*
> No fuss, no muss.
It's not great, I need to wrap RPM with a shell script to do that reliably.
I'm not going to go into long details on our filesystem scanning/syncing
system but the fact that they show up on disk and they keep changing values
even if you do something as simple as rpm -q, is a fair problem here.

Because rpm is not a single binary but ends up calling a bunch of sub
commands each with their own exit path, adding an exit handler in rpm.c
won't do it, so to be safe I might even ben looking at a shell wrapper for
rpm :-/

> > As you know 
> > 1) older rpms (much older) ran fine without having to create them for any
> >   rpm operation.
> > 2) rpm -q as root creates them but rpm -q as a user doesn't.
> > 
> > My questions:
> > 1) it is the db library that is creating them, right?
> Yes. The __db* files are how interprocess locks are shared
> in Berkeley DB. Its known as a DBENV.

and those were not needed in rpm 4.0.x and it worked fine without them.
Do newer rpms call bdb differently or did it just upgrade bdb to a version
that requires __db*?

> > 2) can't it be told to stop making when it's called?
> You're barking the wrong tree. Databases (with concurrent access) need locks,
> the locks are shared in an environment, and the environment is carried
> in __db* files in the Berkeley DB implementation.

Understand I can't make that point to people when rpm 4.0.x worked great
without them. Unfortunate they are enough of a problem for us that people
are actually asking me to revert back to rpm 4.0 as a result of this.

I realize we don't have a typical use, but eh, it's there and I can't break

> > 3) rpm -q as a user doesn't create the lock/cache files and needlessly
> >   creates them when it's root. Can't rpm be told not to make them at 
> >   all for at least read only operations?
> Yep. That doesn't mean correct, only that non-root risks segfaulting
> if a database is changing while the non-root query is running.

A potential segfault due to concurent access we don't have anyway would be
much more acceptable to us :)

If you have any idea if BDB can be made to stop since it was doing without
them before and that usage worked for us, and has for years, that'd be
If not, I guess, I'll just wrap rpm around an rm shell script.

"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
Received on Tue May 25 19:23:31 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.