On Tue, 11 Mar 2008, Marantz, Roy wrote:
I'm running OpenLDAP 2.4.8 with Berkeley DB 2.4.6 on Solaris-10 compiled with Sun's compiler.
Are you sure you haven't typoed the bdb version number here? I mean, the most significant digit should be a "4", if nothing else...
Look for the slapd log message from bdb_open (-d trace) to find your Sleepycat version.
If I start and stop slapd in short succession it will hang after the 2nd or 3rd time. Following are the syslog message, a pstack (backtrace), and sanitized copy of slapd.conf. Any help in debugging this would be appreciated. Mar 11 16:00:33 master.nyc.deshaw.com slapd[3995]: [ID 100111 local4.debug] slapd starting Mar 11 16:00:39 master.nyc.deshaw.com slapd[3995]: [ID 543694 local4.debug] daemon: shutdown requested and initiated. Mar 11 16:00:39 master.nyc.deshaw.com slapd[3995]: [ID 542995 local4.debug] slapd shutdown: waiting for 0 threads to terminate
Your point is that you're hanging on a shutdown that you initiated, right? Or is it that slapd refuses to fully start and/or is exiting on its own volition shortly after startup or.....?
13476: /usr/local/openldap/libexec/slapd -u ldap -g ldap ----------------- lwp# 1 / thread# 1 -------------------- fe001117 lwp_wait (2, 80476f8) fdffd326 _thrp_join (2, 0, 0, 1) + 5a fdffd4a5 pthread_join (2, 0, 80871e0, 0) + 2b 08088b02 slapd_daemon () + 7a ----------------- lwp# 2 / thread# 2 -------------------- fe00040b lwp_park (0, 0, 0) fdffac7a cond_wait_queue (83114ac, 8311494, 0, 0) + 68 fdffb146 _cond_wait (83114ac, 8311494) + 66 fdffb188 cond_wait (83114ac, 8311494) + 21 fdffb1c1 pthread_cond_wait (83114ac, 8311494, a7, 821603c) + 1b 08196c6c ldap_pvt_thread_pool_destroy (fe000542, 0, 83114cc, fdee8ec0, fdc70000, 0) + e4 083114c8 ???????? ()
Well, easy enough, figure out lock it's waiting for ;)
I think the "shutdown you asked for" interpretation is right, so under that theory:
Seeing as you're at shutdown, my guess would be it's trying to close the bdb database in
directory /var/openldap/nyc.example.com/data
so go there, run db_stat -CA, and see what locks are still held. Assuming that you've initiated a shutdown, there really shouldn't be anything left...although there might be more going on. For example, syncrepl might still be going even if you haven't done anything "by hand." (Although your stack trace and syslogs belie that...)
But hey, why guess...turn up debugging, do you see the database being closed right?