Howard Chu wrote:
Curt Blank wrote:
Thank you, that explanation helps. There are probably a lot of stale
locks in there now because I have aborted slapcat a number of times now.
Let me ask this, would doing a db_verify also clear this up? The
reason I ask is that last week when I was having this problem after a
test slapadd load I did a db_verify and after that slapcat seems to
have then worked every time.
I trust you've actually read the db_verify documentation:
http://www.sleepycat.com/docs/utility/db_verify.html
Yes I did and I even have a hardcopy of it sitting here on my desk.
Note that the db_verify utility operates on individual database files,
it doesn't do anything to the database environment. And it explicitly
does nothing related to locks, so I would expect it won't affect the
situation. The only thing that cleans up a stale environment is to
perform a recovery.
Yeah see that is what I thought but I had to ask because the only thing
I did was the db_verify to all the bdb files and then slapcat started
working properly.
If I cannot explain the why of something and correct it then there is
always the possibility of it returning at the most inopportune moment.
Even though this is our master ldap server it really does not do a lot
of updating except when we run data fed updates, so I highly doubt there
were any updates occurring causing lock conflicts. And due to other
issues we have not yet run the feed on it since it was built with
slapadd so about the only thing being updated would be user passwords
and some user based Calendar preferences.
So, could slapadd have left stale locks?
Howard Chu wrote:
Curt Blank wrote:
Thanks, I'll give that a shot when I can schedule an outage,
hopefully overnight tonight.
Further info: This is a new ldap server just bought online with
v2.2.24, as such is was loaded from scratch using ldapadd without
any errors. Then immediately after starting slapd this slapcat
problem was there, so I'm just curious as to what the db_recovery
is expected to do? I would think the db would be pristine from just
being loaded.
Generally it is safe to use slapcat and slapd simultaneously when
using back-bdb and back-hdb, but if slapd is busy doing database
updates, it will have outstanding locks that may impede slapcat's
progress. (And vice versa, slapcat only obtains read locks but it
may temporarily prevent slapd from obtaining a write lock that it
needs.)
If you see a hang like this when slapd is not running that generally
means there are stale locks leftover in the database environment
from an abnormal termination of some previous run. Also note that in
the current version, interrupting slapcat before it completes will
also leave stale locks in the database. That is what db_recover will
clear up.
In the next release (2.3.xx) we have added automatic detection of
abnormal shutdowns, which will make all recovery fully automated,
and this kind of situation should never arise any more.