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

Re: slapcat hangs v2.2.24

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:

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.