[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