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

Re: ldap deadlock?

I think 2.2.28 uses the "long-lived TXN patch," and that's Now Considered Harmful. If I remember right, under that code, a simultaneous slapcat and write would result in an hdb deadlock. However, I'm not sure if that would affect slapcats of bdb. See ITS #4088 and http://www.openldap.org/lists/openldap-commit/200510/msg00234.html.

"no connection" messages are currently considered safe.

On Wed, 9 Aug 2006, Curt Blank wrote:

Ok, I think my eyes just popped open a bit here, I was assuming something could not/would not happen.

Let's say I have a pristinely clean db, no outstanding locks, I start up slapd, it runs fine, never dies, never is stopped and started, is not accessed by anything but slapd, slapcat, and db_checkpoint (each always successfully) while it is running, can a lock go stale in that environment?

My gut feeling here is that the answer is going to be yes, thus being the root cause of these occurrences. In my ideal world I never expect that to/could happen...

Furthermore, I see these on occasion:

connection_read(62): no connection!

Sometimes this occurs right after the ACCEPT without a corresponding op= ENTRY for that fd. Other times I see it after one or more op= ENTRY operations. This appears to me that the client is not gracefully disconnecting, the "no connection" message can be time stamp the same second as the ACCEPT so I know it's not due to idle timeout. I'm pretty sure the culprit in most of these "no connection" messages is via sendmail on our MTA doing lookups.

Could instances of these be causing stale locks??