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

Re: (ITS#6334) hang during ldapmodify

--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.
       -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.



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