[Date Prev][Date Next]
Re: (ITS#6334) hang during ldapmodify
--On Wednesday, October 21, 2009 12:51 PM -0400 Mark Dieterich
>> 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.
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.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration