--On Wednesday, October 21, 2009 12:51 PM -0400 Mark Dieterich mkd@cs.brown.edu wrote:

...

I just found that if I run the server side using "-d -1" (i.e., /usr/sbin/slapd -d -1 -f /etc/ldap/slapd.conf) I never hit the lockup.

Well... for better or worse, if I run my test case with "-d -1" it still hangs. Last portion of the debug output is:

tls_read: want=5 error=Resource temporarily unavailable sasl_generic_read: want=3, got=0

ldap_read: want=8, got=0

very similar to what we were seeing before.

Ok. Since this still hangs for you, what we really need is the logs generated by slapd. This seems to specifically be a server side issue. If you could run:

/usr/sbin/slapd -d packets -f <conf file> (or however you start slapd, but specifically using packets), and dump that to a file, like:

/usr/sbin/slapd -d packets >/tmp/packets.txt 2>&1 (or whatever for your shell, etc), run your modify, and then stop the server (control-c should be graceful from the startup terminal), and then get us that log, it would be most appreciated. I can't get it to lock @ Stanford using loglevel packets, so I can't gather the data myself.

Please read over the security concerns about loglevel packets in the slapd(5) man page as well. I don't think you really care since you are using SASL/GSSAPI, but there may be sanitization you want to do. http://www.openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html -d debug-level Remember that if you turn on packet logging, packets containing bind passwords will be output, so if you redirect the log to a logfile, that file should be read-protected.

Thanks, Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration