[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: multiple subordinates and shm_key - not a good idea

On 4/26/06, Howard Chu <hyc@symas.com> wrote:
> matthew sporleder wrote:
> > I am using openldap 2.3.21 and bdb 4.4.20 (both compiled 64-bit) on solaris 10.
> >
> > It seems that using multiple shm_keys in slapd.conf with many
> > subordinate databases results in unusable data.  I'm about to try and
> > re-import with the same shm_key on all of the subordinates.  (ugh!)
>
> Shared memory is managed directly by the BerkeleyDB library, not
> OpenLDAP itself. Whether a database is subordinate or not in OpenLDAP
> has no impact on BerkeleyDB; BerkeleyDB hasn't got any clue of what the
> calling application is doing with those databases and keys. All
> BerkeleyDB knows is that you're accessing multiple distinct database
> environments. Each BDB environment must be completely separate. When
> you're using BDB with plain environment files, you must configure them
> all in separate filesystem directories. When using shared memory regions
> the requirement doesn't change; every environment must be separate.
> Using the same shm_key for all the environment regions is guaranteed to
> fail.
>
> It's not a good idea to try to use shared memory without reading the
> standard Unix documentation on shared memory. See the ipcs manpage for
> information on diagnosing shared memory usage. Notice that a single BDB
> environment is composed of many shared memory regions, occupying a range
> of keys starting from the one you specify and on upward. You can't use
> consecutive keys in your configuration because the subsequent keys are
> already in use.

Okay, I re-added the databases using shm_key's of 1000, 2000, 3000,
and 4000 in slapd.conf. (although all of my keys have been in the 10's
so far)
I read up on ipcs and friends, and now I have a lot of confusion,
which is better than a lot of nothing.  Thanks for that direction.  :)

Anyway, here's the behaviour now:
I can start the database cleanly once, ipcs shows nine ID's being
created, and slapd runs fine.  After this, I shutdown slapd, which
exits cleanly. (after no activity or read-only activity)  When I try
to restart, I get a message about shmat trying to open an ID that is
the lowest number from ipcs+1.  This ID does not exist in the output
of ipcs, so this fails.

If I manually run db_recover, I get messages about shmat
(ID+1,2,3,4,5) not existing, and then I can restart again.  I can also
ipcrm all of my shm ID's from ldap, run db_recover, get fewer
messages, and then restart cleanly.  After both of these, ipcs shows a
new set of ID's.

http://www.sleepycat.com/docs/api_c/env_set_shm_key.html does explain
that bdb is trying to open the keys +1,2,3,4,N, but why isn't it able
to restart without the recover?

So my questions so far:
So is this a bug because I'm using bdb4.4.20?
Should I just add db_recover to my init script?  I thought openldap
2.3 was supposed to handle that. (init.c does mention recover in the
shm section, so I'm at a bit of a loss)

(This is on a normal ufs partition, not NFS)