Re: Slapd fails to die (ITS#2502)

[Villy Kruse <vek@pharmapartners.nl>]

On Thu, 5 Jun 2003, Jason Townsend wrote:

> Date: Thu, 5 Jun 2003 13:37:55 -0700
> From: Jason Townsend <jtownsend@apple.com>
> To: openldap-devel@OpenLDAP.org
> Subject: Re: Slapd fails to die (ITS#2502)
>
> 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. We could create a stamp file in the db directory to
> > indicate a clean shutdown - check for the file at database init, if it
> > exists, maybe do recovery. create stamp file, and delete it on database
> > shutdown.
> >
> > If we put the slapd PID into the stamp file, then we can check its
> > validity -
> > if the PID is valid and != current PID, everything is OK. If not, then
> > do
> > recovery.
> >
> > This probably cannot be the slapd.pid file that's already configured in
> > slapd.conf because that file is optional, and we want something that
> > will
> > always be used.
>
> 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.

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.

Villy