"rpm -q" has race conditions when run as root?

[James Ralston <qralston+ml rpm andrew cmu edu>]

I've noticed some real flakiness with rpm (Red Hat 7.2 i386, all
errata applied, rpm-4.0.3-1.03).

As I previously posted, I use this command:

/bin/ls -1 *.rpm | ( while read P; do rpm -q `echo "${P}" | sed -e 's/-[^-][^-]*-[^-][^-]*$//g'` 1>/dev/null 2>&1 && echo "${P}"; done ) | ( while read P; do rpm -q `echo "${P}" | sed -e 's/\.[^\.][^\.]*\.[^\.][^\.]*$//g'` 1>/dev/null 2>&1 || echo "${P}"; done )

...to enumerate the RPMs in the current directory which are (probably)
newer versions of already-installed RPMs.  I run this in the directory
into which I download errata RPMs.

Occasionally this command returns false positives; that is, it emits
the names of already-installed RPMs.  But it did so in a (seemingly)
non-deterministic manner.  I was curious, so I tracked down what was
happening.  When I eliminated the "1>/dev/null 2>&1" redirections, I
got this output:

package Mesa-3 is not installed
Mesa-3.4.2-10
Mesa-3.4.2-10
package Mesa-demos-3 is not installed
Mesa-demos-3.4.2-10
Mesa-demos-3.4.2-10
package Mesa-devel-3 is not installed
Mesa-devel-3.4.2-10
Mesa-devel-3.4.2-10
[...]
package enscript-1.6 is not installed
enscript-1.6.1-16.2
enscript-1.6.1-16.2
package foomatic-1.1-0 is not installed
foomatic-1.1-0.20011018.7
foomatic-1.1-0.20011018.7
gdb-5.1-1
gdb-5.1-1
ghostscript-6.51-16
rpmdb: region error detected; run recovery.
error: db3 error(-30987) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 -  (-30987)
ghostscript-6.51-16
package glibc-2.2 is not installed
glibc-2.2.4-19.3
glibc-2.2.4-19.3
package glibc-common-2.2 is not installed
glibc-common-2.2.4-19.3
glibc-common-2.2.4-19.3
package glibc-devel-2.2 is not installed
glibc-devel-2.2.4-19.3
glibc-devel-2.2.4-19.3
[...]

As far as I can tell, the failure mode is a race condition of some
sort; it appears to be non-deterministic.

The other interesting factor is that rpm only seems to fail this way
when I run the above command as root.  If I run the command as an
ordinary user, it never seems to fail.

Perhaps not coincidentally, when I run the command as root, these
(assumably) temporary files appear and disappear in /var/lib/rpm:

    __db.001
    __db.002

I wouldn't be surprised to see temp files during an install or erase,
but during a *query*?  And why do they seem to be associated with the
race conditions?

Jeff, can you shed any light on this?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA