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

RE: Slapd fails to die (ITS#2502)



> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Villy Kruse

>
> On Thu, 5 Jun 2003, Jason Townsend wrote:

> > On Friday, May 9, 2003, at 4:38 PM, Howard Chu wrote:
> > > So it turns out that there were read locks left in the
> BDB environment
> > > from a
> > > prior crash of slapd. Seems like we may need to do an
> auto-recover on
> > > slapd
> > > startup after all.
> >
> > Has this change been implemented yet? If not, I'll take a
> look at doing
> > this.

> Could an exclusive lock on a specific lock file located in the same
> directory as the DB files be an idea?
>
> Before opening the environment try to get an exclusive lock
> on the lock
> file and if the lock is granted open with recovery.  When the recovery
> is completed downgrade the lock to a shared lock.

> If the exclusive lock is not granted try to get a shared
> lock, this time
> use the blocking lock call.  When the lock is granted we know
> the other
> process has finished the recover, and we can now open the environment
> without the recover option.
>
> That should work for the server as well as for slapcat and slapadd.

Sounds good.

> If you were to use db_recover to recover the database you would need
> to make sure the slapd isn't currently running, I presume.

Yes.

Seems like an fcntl lock on byte 0 of the id2entry database would be good
enough.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support