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

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



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