On May 23, 2012, at 3:43 PM, Patrick Hemmer <openldap(a)stormcloud9.net <mailto:openldap@stormcloud9.net>> wrote: > I have a database which was working fine, but now whenever I go to > perform any sort of modification on the database, the modification > just hangs. No error, no timeout, just sits there. However while that > first modification is hung, I can perform modifications of another > database (other than cn=config) and they work just fine. I can even > do further searches against cn=config while the modification is still > hung. > Also when I run slapd in the foreground, and then send it a SIGINT, > it says "slapd shutdown: waiting for X operations/tasks to finish" > and never ends. I end up having to SIGKILL it. > > The database is part of a MMR group of servers I was building, but I > shut down all the other servers to troubleshoot the issue (it makes > no difference whether the other servers are up or down, and they all > exhibit the same problem). > > Where should I start looking to figure out whats going on (the > specific operation/task thats hanging)? I can run slapd in debug mode > with '-1', but theres a ton of info, and I dont know whats relevant, > or which debug mode I should use other than '-1'. > > Thanks > > -Patrick Always state the version of OpenLDAP you are running. I know for a fact this is a known bug in older releases of OpenLDAP 2.4 because I reported it. --Quanah

<snip>

Ok, so the problem went away. Didnt change a thing, just came back after a few hours, started slapd up, and it behaved (though I am still interested to know how to find stuck operations/tasks). However a new (maybe related?) issue has popped up. I tried to add olcSpReloadHint=TRUE to the syncprov overlay (all the replicas are > 2.3.11) and this change isnt replicating (other changes, including attribute adds, to other DNs in cn=config replicate fine, just not this one). running the consumer slapd with `-d sync` I get the following: 4fbd9472 syncrepl_message_to_entry: rid=510 DN: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config, UUID: 84beea9e-3987-1031-9a75-776905f7a32d 4fbd9472 syncrepl_entry: rid=510 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 4fbd9472 syncrepl_entry: rid=510 be_search (0) 4fbd9472 syncrepl_entry: rid=510 olcOverlay={0}syncprov,olcDatabase={0}config,cn=config 4fbd9472 syncprov_matchops: skipping original sid 033 4fbd9472 null_callback : error code 0x50 4fbd9472 syncrepl_entry: rid=510 be_modify olcOverlay={0}syncprov,olcDatabase={0}config,cn=config (80) 4fbd9472 syncrepl_entry: rid=510 be_modify failed (80) 4fbd9472 do_syncrepl: rid=510 rc 80 retrying

--On May 24, 2012 10:41:32 AM -0400 "Patrick H." <openldap(a)stormcloud9.net&gt; wrote: > Sent: Wed May 23 2012 22:03:39 GMT-0400 (EDT) > From: Patrick H. <openldap(a)stormcloud9.net&gt; > To: Patrick Hemmer <openldap(a)stormcloud9.net&gt; > openldap-technical(a)openldap.org > Subject: Re: slapd hangs upon performing modification of cn=config > > <snip> > > > I changed the subject as this is a different issue than originally > reported. While they may be related, its safer to assume they're not. > > > > Ok, so the problem went away. Didnt change a thing, just came back after > a few hours, started slapd up, and it behaved (though I am still > interested to know how to find stuck operations/tasks). > However a new (maybe related?) issue has popped up. I tried to add > olcSpReloadHint=TRUE to the syncprov overlay (all the replicas are > > 2.3.11) and this change isnt replicating (other changes, including > attribute adds, to other DNs in cn=config replicate fine, just not this > one). I'm going to assume you mean all replicas are > 2.4.11, not 2.3.11. All your replicas should be running the same version of OpenLDAP. All your replicas should be running a current version of OpenLDAP. Some of the fixes to Syncrepl have been on the client side, not just the master side. If you can reproduce using 2.4.31 on all nodes, you should probably file an ITS. --Quanah