RPM Community Forums

Mailing List Message of <rpm-users>

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

From: Jeff Johnson <n3npq@mac.com>
Date: Tue 25 May 2010 - 19:57:52 CEST
Message-id: <4174341F-B92F-4475-BB0F-C8C6A677FC1C@mac.com>

On May 25, 2010, at 1:23 PM, Marc MERLIN wrote:

> 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.
> 

Not true. I've already pointed you at code (and I believe its
just setting a configuration macro) that will _AUTOMATICALLY
remove __db* files at the end of every invocation.

The code used to be there, just I've not looked for years ...

> 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*?
> 

Bzzzzt! rpm-4.0.x went end-of-life like 8 years ago.

Stop trolling FUD questions please ...

>>> 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.
> 

Nothing wrong with satisfying your customers at all.

> I realize we don't have a typical use, but eh, it's there and I can't break
> it.
> 
>>> 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 :)
> 

So run as non-root always. RPM will not create __db* files if it
cannot write to /var/lib/rpm.

> 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
> great.

Sure there's lots of ways, all of them quite b0rken.

If you simply wish no locking whatsoever (and everything you ask
indicates this) then set "private" and unset "use_environ_I_forget".

Grep into /usr/lib/rpm/macros for the details. The token parser implementation
is in in rpmdb/dbconfig.c, and there's _ALREADY_ more than enough configuration
implemented in RPM (and going all the way back to rpm-4.0.x) for you to
blow every single toe off of both your feet by disabling locks and
disabling using an environment and enabling a global fcntl lock
and automagically removing __db* files and even automagically
running (*DB->verify) at end of every rpm invocation.

> If not, I guess, I'll just wrap rpm around an rm shell script.
> 

Or use a shell script, doing
	rm -f /var/lib/rpm/__db*
in a shell script is quite KISS and easily achieved.

73 de Jeff
Received on Tue May 25 19:58:13 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.