erici@motown.cc.utexas.edu wrote:

Full_Name: Eric Irrgang Version: 2.3.34 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14)

Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared memory segment for the db cache, the automatic bdb database recovery fails after a reboot (because the shared memory segment doesn't exist yet).

In fact there is no automatic DB recovery happening here, this is a regular Open that fails because the (shared memory) environment is missing. We don't detect that recovery is needed because presumably slapd exited cleanly at the previous shutdown.

I guess we'll have to add a check for this condition (e.g., if ENV open fails and we're using shared memory, recover and try again).

slapd logs show the following: [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable to attach to shared system memory region: Invalid argument [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore from backup! [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint interface requires an environment configured for the transaction subsystem [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument (22) [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) [ID 948119 local3.debug] bdb_db_close: alock_close failed [ID 486161 local3.debug] slapd stopped. [ID 432338 local3.debug] connections_destroy: nothing to destroy.

db_recover must be used to clean up the environment. It gives the message "db_recover: shmat: id 0: unable to attach to shared system memory region: Invalid argument" but completes with return code 0, removes the __db.001 file, and slapd is then able to start without errors.