Re: overlay order important and not documented?

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:
> Francis Swasey wrote:
> > I have found using OpenLDAP 2.3.34 on a RHEL4 system (a locally built 
> > RPM) that the order of the overlays can lead to a problem (slapd locks 
> > up and doesn't do anything).

It's already documented that overlays are executed in a specific order. 
Obviously if the order didn't matter we wouldn't worry about it.

> > I have found that using syncprov, accesslog, auditlog, unique will 
> > work fine.  But, adding refint to the end of that chain and then do a 
> > modrdn that triggers refint to want to change an attribute in another 
> > entry and your slapd is locked up.  There is now one thread that will 
> > not end and you will only be able to shutdown slapd with a "kill -9".
> >
> > However, if I change the order so that the refint is prior to the 
> > accesslog overlay, then it works.
> >
> > Is this interaction between the two overlays and the importance of 
> > their relative order a known (or at least expected) -- or should I 
> > open an ITS?
>
> AFAIK, it is not known, although some strange and adverse interaction is 
> possible (and feared).  I suggest you file an ITS.

Not documented... The accesslog overlay serializes all write operations 
by taking a lock. This means only one write operation is allowed to 
progress at any time.

The refint overlay creates multiple write operations from a single write 
operation. If the accesslog overlay has already locked the current 
operation, then yes, the refint overlay will deadlock at that point 
because its write operations still go through the entire overlay stack. 
I think the fix for this will be to change the refint overlay to bypass 
any overlays above it when performing its own writes.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/