Hallvard B Furuseth wrote:

hyc@symas.com writes:

...

h.b.furuseth@usit.uio.no wrote:

...

quanah@zimbra.com writes:

...

You have to run slapd at least once before using the db_stat tool after using slapadd -q. This is a known feature of using -q.

Ah, need doc fix in slapadd.8 then.

What exactly are you trying to do?

Playing around, mostly.

...

slapadd -q disables locking,

I don't see that in the doc. It's reasonable to infer, except I have no idea why even slapadd (without -q) needs so many. I couldn't find an explanation of what does use locks and lockers (FAQ file 893 doesn't say), thus not how many I will need and which of these limits is fatal if I have too few. Can experiment to find out the latter, of course.

These are backend-specific considerations. Feel free to file an ITS against the slapd-bdb(5) manpage if you wish.

In back-[bh]db there are typically up to two transactions per operation, and each transaction uses a single locker. There's also a single reader locker per thread. So at most you need 3 lockers per configured server thread. The BDB default of 1000 is generally more than enough.

Any operation will acquire a lock for every single DB page it touches. The more work that an operation needs to do, the more pages it will touch, the more locks it will need. If you write an entry that has many indexed attributes, or if you have substring indices on attributes with lengthy values, you will need many locks in a single operation. While the number of pages simultaneously held open will depend on the actual distribution of data in the database, an operation will generally need at least one lock per DB file. So, one for a dn2id lookup, one for an id2entry lookup, and one for each defined index. In most cases that's all, but substring indices will generally need a number of locks proportional to the length of the strings being indexed.

Sleepycat messages can be scary. I came from the slapadd "wrong dynamic library" or message or whatever it was which the mailinglist says is cured with more locks & lockers, so I increased those and just got another error message (this ITs). So apparently, something still wrong.

I'm not familiar with that message or advice.

"Not configured for the locking subsystem" sounded like a permanent problem with the database build, not that it would get "reconfigured" to support locking when needed. Hence this report. Oh well.

The message said The Environment is not configured for locking. It didn't say the BDB library. Really there's nothing mystical or spooky here, and if you've actually read the BDB documentation you'll know what The Environment refers to. If you're using back-[bh]db without having read the BDB documentation, despite all the recommendations to do so, you deserve to be scared.

...

so of course there's nothing for db_stat -c to report. There's no breakage here.