RE: RPM locks on Solaris 9 question

["Dennis McRitchie" <dmcr Princeton EDU>]

Hi Tim,

Sorry for the belated reply. I had to deal with something else and just got
back to this problem. Please see my answers to your comments below:

>>So "--enable-posixmutexes" was not set for my build. Would you expect it
to
>>behave the way it does below in that case?

>If it's not set, then did db's configure output (to the screen) indicate
>that it was selecting LWP as the threading implementation?

Yes.

>Read the section in the Berkeley DB docs I reference, specifically the
>"Second" part of what --enable-posixmutexes does.  In particular, the
>implication seems to be that even if you don't force POSIX mutexes, if
>the mutex implementation db's configure selects (probably LWP in your
>case) doesn't support shared mutexes between processes, then only
>DB_PRIVATE environment's will be available.  This seems to match the
>situation you're seeing.

Agree.

>mmap64(0x00000000, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) Err#11
>EAGAIN

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Read the Solaris man page for mmap.  On Solaris 8, the likeliest reasons
for EAGAIN are:


     EAGAIN
           The mapping could not be locked in memory.

           There was insufficient room to reserve swap space  for
           the mapping.



Note also the earlier note in the man pages about page locking.  Is RPM
(or db) calling mlock/mlockall()?  That requires superuser privileges on
many UNIX platforms, Solaris included.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Configure did detect that mlock was present, but truss did not report that
it was called. But perhaps mmap64 calls it under the hood?

In any event, it seems to work fine in the DB_PRIVATE environment, so no
reason not to go with that since Jeff says rpm worked that way for years...

Thanks very much for your help.

Dennis