On May 29, 2007, at 2:32 AM, Thomas Lotterer wrote:

> Your experience wanted! Sorry for bothering you with a topic that only
> scratches RPM, but I wanted to understand why some BDB Applications  
> suck when
> independent processes are run simultaneously. I have experienced  
> those problems
> in the RPM world, too.  They cause sporadic lockups and database  
> corruptions.
> Seldom, but more often if multiple RPMs being run concurrently,  
> e.g. many
> queries, one or two rebuilds and an install. Those lockups and  
> corruption are
> almost impossible to reproduce, but I experienced them multiple  
> times over the
> past few years.
>

I'll be happy to help, but it will have to wait for weekend hacking  
time.

Meanwhile, let me try to point you at rather important functionality in
rpm-4.4.8+, automagic cleanup of stale read locks and (at least mostly)
write locks.

rpm-4.4.8 is insturmented to segfault on demand on both read and write
pathways using
     --rsegfault N
     --wsegfault N

N should be an integer like 100, a random value between 0 and N
is chosen by popt to initialize a counter.

The counter ticks down to 0 and an assertion failure occurs, thereby
simulating a segfault, leaving behind stale locks, and perhaps other
problems/issues in an rpmdb.

Here's what I did to to test rpmdb locking.

Save a copy of your rpmdb just in case
     cd /var/lib
     tar czvf rpmdb.tar.gz ./rpm

In one window run a continuous read loop like
     while true
     do
	rpm -q --rsegfault 100 time
	sleep 5
     done

In another window, run a install/erase loop:
     while true
     do
	rpm -i --wsegfault 100 time*.rpm
         rpm -e --wsegfault 100 time*.rpm
	sleep 5
     done

Watch the results until you understand the cleanup behavior.

I've run multiple copies (anything more than 4 readers and 2 writers
is likely going to be impossible to diagnose, no fork bombs please ;-)
with a couple of simple rpm usage scenarios.

Note that rpmdb_stat -CA (which can display locks) has some issues
with the lock slots if they are turned on. I keep meaning to report
that issue upstream, but rpmdb_stat problems with lock slots is
hardly a make-or-break issue for rpm.

> So I tried to create a small example test case just to see what  
> needs to be
> done to make BDB finally work. I failed - even with the help of the  
> Oracle
> Berkeley DB forum. Can you help me getting my faith in BDB  
> reliability back?
>
> Mark Hatle created another solution to this problem. If his  
> solution really is
> the only way then we should kick BDB out of RPM in favor of SQLite.
>

There's nothing wrong with SQLite at all. I want fastest and most  
reliable
in rpm, that is still Berkeley DB afaik and imho.

> Here are the details (abstracted not mentioning the specific RPM  
> use case)
> http://forums.oracle.com/forums/thread.jspa?threadID=511499&tstart=0
> I hope I did something wrong but even then it means BDB is hard to  
> use.
>

Just judging from the number of times I've shot myself in the foot with
Berkeley DB, it's likely a misuse.

Yes, Berkeley DB, mostly because its a complicated programming API,
is hard to get right. One does not have to look to far to see the number
of successful applications using Berkeley DB to asses "reliable".

Perfect, or easy, are entirely different metrics.

73 de Jeff