I attached a gdb to the new process plus the -d 7 output (you know, that neat thing that unix has called redirection). Hopefully, the connection I have to the computer will not be lost and I will be able to get the trace if it fails. Also, not the results below are just the last part of the output. Let me know if I need more. For what it is worth, I did the 'he' search shown at the bottom below and it did not fail.... Thanks!
-----Original Message----- From: openldap-software-bounces+douglas=gpc.edu@openldap.org [mailto:openldap-software-bounces+douglas=gpc.edu@openldap.org]On Behalf Of Douglas B. Jones Sent: Friday, February 23, 2007 2:22 PM To: openldap-software@openldap.org Cc: douglas@gpc.edu Subject: RE: slapd stopping with no error message
Finally failed, I did not have a gdb on it, but did have -d 7. Below are the results. Thanks!
do_search ldap_read: want=8 error=Resource temporarily unavailable ber_scanf fmt ({miiiib) ber:
dnPrettyNormal: <o=gpc,c=us>
=> ldap_bv2dn(o=gpc,c=us,0) <= ldap_bv2dn(o=gpc,c=us)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=gpc,c=us)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=gpc,c=us)=0 <<< dnPrettyNormal: <o=gpc,c=us>, <o=gpc,c=us> SRCH "o=gpc,c=us" 2 0 100 3600 0 ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: filter: (|(cn=he*)(mail=he*)(sn=he*)) ber_scanf fmt ({M}}) ber: attrs: cn mail *** glibc detected *** corrupted double-linked list: 0x29400048 *** /etc/init.d/gpcldap-33: line 51: 11051 Aborted ${slapd} -d 7 -u $user -h "ldap://:$P/" $OPTIONS $SLAPD_OPTIONS
-----Original Message----- From: openldap-software-bounces+douglas=gpc.edu@openldap.org [mailto:openldap-software-bounces+douglas=gpc.edu@openldap.org]On Behalf Of Douglas B. Jones Sent: Wednesday, February 21, 2007 12:38 PM To: openldap-software@openldap.org Cc: douglas@gpc.edu Subject: RE: slapd stopping with no error message
Howard pointed out that I am still asleep - he stated what to do below '-d 7'. Thanks!
-----Original Message----- From: openldap-software-bounces+douglas=gpc.edu@openldap.org [mailto:openldap-software-bounces+douglas=gpc.edu@openldap.org] On Behalf Of Douglas B. Jones Sent: Wednesday, February 21, 2007 10:52 AM To: 'Howard Chu' Cc: douglas@gpc.edu; openldap-software@openldap.org Subject: RE: slapd stopping with no error message
Slap/slap/slap - waking up now - sorry not much sleep since last week - sick child, still should never forget the most basic. I will redirect. Question: what level of debug would you recommend. Thanks!
-----Original Message----- From: openldap-software-bounces+douglas=gpc.edu@openldap.org [mailto:openldap-software-bounces+douglas=gpc.edu@openldap.org] On Behalf Of Howard Chu Sent: Wednesday, February 21, 2007 10:43 AM To: Douglas B. Jones Cc: openldap-software@openldap.org Subject: Re: slapd stopping with no error message
Douglas B. Jones wrote:
About three times in the last several days, ldap-2.3.33 (RHEL4) has just stopped. No core or error messages in the log files. The last entry in the log file is just a search entry, with nothing common in the search from 'crash' to 'crash'. I have even tried the searches and they worked fine. I restart it notes an unclean shutdown detected and attempts recovery and appears to do so.
My question is what is the proper way to debug this. If I do -d, it will not fork, but since it fails at random times I probably will not be there to see the output.
Unix has this cool thing called I/O redirection, perhaps you've heard of it? There's also this other cool thing called job control...
In [t]csh I would use slapd -d 7 >& Errs & In sh I would use nohup slapd -d 7 > Errs 2>&1 &
And if any of that looks unfamiliar to you, then you Really Really need to go read Kernighan & Pike's _The_Unix_Programming_Environment_ before you do anything else.
Is this the best way to try to see what is happening? If so, what is the recommended debug level? It was built with:
./configure \ --prefix=/usr/local/openldap-2.3.33 \ --includedir=/usr/local/lib/BerkleyDB.4.5.20.NC/include \ --enable-crypt \ --enable-cleartext \ --enable-debug \ --enable-meta=yes \ --enable-monitor=yes \ --enable-relay=yes \ --enable-ldap=yes \ --enable-rewrite=yes \ --enable-overlays=yes \ -exec-prefix=/usr/local/openldap-2.3.33
I see that there is 2.3.34 out and that it can use BDB 4.5. Is the best course of action to upgrade?
All OpenLDAP 2.3.x releases work with BDB 4.5 (and 4.6, for that matter). The explicit test in configure is just a formality. (If the configure test didn't find a specific BDB version that it recognized, it would eventually fallback to -ldb4 which would work anyway.)