Re: RPM locks on Solaris 9 question

[Jeff Johnson <n3npq nc rr com>]

Dennis McRitchie wrote:

> Hi Jeff,
>
> I saw your post (pasted below) on another forum about how to resolve a
> "Resource temporarily unavailable" error and have a couple of related
> questions.
>
> I just successfully built and installed rpm 4.2 on Solaris 9 (I gave up on
> debugedit though). When I typed in:
> $ rpm --initdb
>  

--initdb is mostly a noop these days, might be useful for debugging this 
particular
problem, as it creates an environment, opens a database, then closes.

I dunno off hand how many files are created, but file creation will need 
write
access to /var/lib/rpm, usually root iss required.

> I got:
> rpmdb: mmap: Resource temporarily unavailable
> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
> error: cannot open Packages index using db3 - Resource temporarily
> unavailable (11)
>  

Hmmm, something in Berkeley DB (or rpm's config thereof) is breaking.

Throw truss on that, see if you can't find what syscall is failing.

> Then I tried:
> $ rpm --rebuilddb
>
> and got:
> rpmdb: mmap: Resource temporarily unavailable
> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
> error: cannot open Packages index
>
> Both before and after these commands, there were no files in /var/lib/rpm.
> So I followed your final piece of advice below and created a macros file
> with:
> %__dbi_cdb create cdb mpool mp_mmapsize=16Mb mp_size=1Mb private
>  

private disables locking in Berkeley DB, uses malloc'd memory iirc.

> and then retried:
> $ rpm --initdb
>
> This time it worked and __db.001 and Packages were created in var/lib/rpm.
>
> My questions are:
> 1) What are the implications of disabling concurrent access locks, and
> re-enabling fcntl(2)
> lock on packages? This build of rpm and all related files are on a mounted
> file system. If multiple users (mounting this file system from different
> machines) were to try to install packages on their local systems at the same
> time, would this be a problem?

You can probably live with no rpmdb locking, rpm-4.0.[34] essentially 
had no locking
and the world did not darken ;-)

Most database access is readonly, your likeliest failure is a segfault 
from reading
a data structure that was being written by concurrent install. Still, 
figgering the
mmap problem is better, it can't be that hard to fix. Try running the 
tcl test scripts,
see if that has the same problem.

> 2) If I were to subsequently upgrade to kernel+NPTL and glibc+NPTL, then
> what do I need to do to go back to concurrent access locks? Just remove the
> newly created macros file?
>
>  

Hmmm, you've switched platforms here somehow. Removing the macros file will
use the default configuration, which uses concurrent locks.

rpm cares about NPTL only through Berkeley DB, there are 2 occurences of 
--enable-posixmutexes
used to configure Berkely DB. Nuke those, and don't worry about NPTL. 
You will lose unified
thread/process locks and you won't care.

Note that you must build on a NPTL system with --enable-posixmutexes, 
there's a test
deep in Berkely DB configure that needs to be run on a NPTL enabled 
build system.

HTH

73 de Jeff