Re: MOD attr=uniqueMember - Was: Re: slapd just silently dies

[Howard Chu <hyc@symas.com>]

Repeating an earlier post - syslog output is not useful for debugging 
purposes.

If you want to track down what's going wrong here, run slapd under a 
debugger and get a backtrace from when it dies.

There's no point to making blind guesses.

fuser9bb@hotpop.com wrote:

> Okay, I made some progress. It appears that *sometimes* when a 'MOD 
> attr=uniqueMember' op is performed that slapd silently dies. There is 
> definately a pattern. Following is an example:
>
> Apr 22 13:49:00 serv slapd[5631]: conn=36 op=0 BIND 
> dn="cn=Manager,..." mech=SIMPLE ssf=0
> Apr 22 13:49:00 serv slapd[5631]: conn=36 op=0 RESULT tag=97 err=0 text=
> Apr 22 13:49:00 serv slapd[5631]: conn=36 op=1 SRCH base="dc=..." 
> scope=0 deref=0 filter="(dc=....)"
> Apr 22 13:49:00 serv slapd[5631]: conn=36 op=1 SEARCH RESULT tag=101 
> err=0 nentries=1 text=
> Apr 22 13:49:00 serv slapd[5631]: conn=36 op=2 UNBIND
> Apr 22 13:49:00 serv slapd[5631]: conn=36 fd=8 closed
> Apr 22 13:49:16 serv slapd[5631]: conn=37 fd=8 ACCEPT from 
> IP=.......:47567 (IP=0.0.0.0:389)
> Apr 22 13:49:16 serv slapd[5631]: conn=37 op=0 BIND 
> dn="cn=Manager,..." method=128
> Apr 22 13:49:16 serv slapd[5631]: conn=37 op=0 BIND 
> dn="cn=Manager,..." mech=SIMPLE ssf=0
> Apr 22 13:49:16 serv slapd[5631]: conn=37 op=0 RESULT tag=97 err=0 text=
> Apr 22 13:49:16 serv slapd[5631]: conn=37 op=1 MOD dn="cn=..."
> Apr 22 13:49:16 serv slapd[5631]: conn=37 op=1 MOD attr=uniqueMember
>
> (here is where slapd dies and our script notices this and restarts slapd)
>
> Apr 22 13:50:09 serv slapd[5795]: slapd starting
>
> So out of perhaps thirty MOD attr=uniqueMembers ops, several may cause 
> slapd to die. No other operations are causing this, nor or any other 
> attrs with the MOD op that we have found. The MOD attr=uniqueMembers 
> ops occur very fast by an app that we use to manage our users and 
> their group memberships in OpenLDAP.
>
> Could this be caused by a corrupt ldbm file? If so would the following 
> operation fix this problem?
>
> 1. stop slapd
> 2. slapcat > x
> 3. import slapcat file
> 4. start slapd
>
> I want to get my ducks lined in a row before we move forward.
>
> Or could this be something else entirely?
>
> fuser9bb@hotpop.com wrote:
>
> > Hi. We are using openldap-2.2.15 built from source hosted on RHES3. I 
> > know that 2.2.24 is the current version, but I don't think we are too 
> > far behind the curve. Would prefer to not upgrade if possible, but we 
> > are open to it.
> >
> > Anyway, here is our problem. We have a master openldap server running 
> > 2.2.15. The server runs both slapd and slurpd. In the past few weeks, 
> > we have seen slapd just die. We can't find any errors in 
> > /var/log/messages or /var/log/openldap.log (where we have slapd 
> > messages going via syslog). Frankly, we don't know why slapd is dying.
> >
> > I would like some pointers on troubleshooting the situation. 
> > Currently, I have loglevel set to 256. I can increase the loglevel, 
> > but it's hard to leave the loglevel on a high value for long since 
> > the log file will grow VERY rapidly. Right now we can't pin down the 
> > exact cause or timing of slapd dying, so I would need to leave 
> > loglevel high for a while.
> >
> > Anyway, any known issues that would cause this for 2.2.15? Any 
> > suggestions for troubleshooting this problem?


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