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

Re: (ITS#4851) improper database recovery at startup when using shared memory for db cache

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

   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   Chief Architect, OpenLDAP     http://www.openldap.org/project/