On Tue, Aug 24, 2004 at 02:49:11PM -0700, Shawn Weber wrote: > We have an automated third-party tool that builds a tree of code, called > CruiseControl which some of you might be familiar with. Occasionally, > an automated build will fail when trying to acquire a read-only lock on > the rpm database. > Probably because another process has an exclusive fcntl lock. > The error message itself looks something like this in the logs: > > error: cannot get shared lock on /var/lib/rpm/Packages > error: cannot open Packages index using db3 - Operation not permitted > (1) Hmmm, this smells like rpm-4.0.4 or earlier. That the case? > > The main problem is that this error confuses a developer, since the > error message that our automated build system (CruiseControl) returns is > rather cryptic and the detailed build log must usually be inspected to > determine that this is the root cause of the problem. > > Does anyone know what can be done to alleviate this error from > occasionally occuring, such as explicitly locking and unlocking the db? > The solution will be to participate in the locking scheme that rpm uses, basically shared/exclusive fcntl locks on /var/lib/rpm/Packages. The first step, however, is gonna be to understand what process has the exclusive lock, as you will not be able to get a shared lock until the exclusive lock is relinquished. Alternatively, use Berkeley DB concurrent access locks, been in "production" rpm since rpm-4.1 (currently rpm-4.3.2 something) several years now, and (mostly) avoids fcntl locks entirely. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj@xxxxxxxxxx (jbj@xxxxxxx) Chapel Hill, NC _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
