Jason Lixfeld wrote: > Anyone know what caused this, or how to fix? Google hasn't told > me anything I can understand about this error. > => bdb_last_id: get failed: DB_BUFFER_SMALL: User memory too > small for return value (-30999) > bdb_db_open: last_id(/var/db/openldap-data/ario) failed: > DB_BUFFER_SMALL: User memory too small for return value (-30999) This should never happen. Seems the only way it could is if you installed a new software version on top of an older database. Naturally, you are never supposed to do that...

> Running: > openldap-client-2.3.37 > openldap-server-2.3.37 > db44-4.4.20.4 > FreeBSD 6.1-RELEASE-p3 > . -- -- 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/

Jason Lixfeld wrote: > On 14-Sep-07, at 6:44 AM, Howard Chu wrote: >> Jason Lixfeld wrote: >>> Anyone know what caused this, or how to fix? Google hasn't >>> told me anything I can understand about this error. >>> => bdb_last_id: get failed: DB_BUFFER_SMALL: User memory too >>> small for return value (-30999) >>> bdb_db_open: last_id(/var/db/openldap-data/ario) failed: >>> DB_BUFFER_SMALL: User memory too small for return value (-30999) >> This should never happen. Seems the only way it could is if you >> installed a new software version on top of an older database. >> Naturally, you are never supposed to do that... > I've been using 2.3/4.4 for as long as I can remember. Updating > via FreeBSD portupgrade which shouldn't bump major versions. > More importantly, how to fix? slapcat ; rm ; slapadd ? Or is > there a less destructive way? slapcat will fail the same way here. Whatever you last did to change either the software or the DB, you'll have to undo yourself or simply start over. This error indicates that an item being requested from the DB is larger than expected. Since the item in question is a fixed size, as I said before, this should never happen. Another possibility is that you created the DB on a 64-bit machine and are now trying to read it with 32-bit code, since that would also affect the size of the item in question.

>>> Running: >>> openldap-client-2.3.37 >>> openldap-server-2.3.37 >>> db44-4.4.20.4 >>> FreeBSD 6.1-RELEASE-p3 >>> . -- -- 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/

Jason Lixfeld wrote: > On 14-Sep-07, at 12:18 PM, Howard Chu wrote: >> Another possibility is that you created the DB on a 64-bit >> machine and are now trying to read it with 32-bit code, since >> that would also affect the size of the item in question. > That's exactly what happened - my master is on amd64, slave is on > i386. I had slurpd running, but couldn't figure out if the > databases were sync'd. The servers hadn't been talking in > awhile, so I figured the easiest thing to do was to sync up the > databases again manually, then fire up slurpd. You are never supposed to copy the raw database files around. slapcat/slapadd are the only documented means for backing up/ migrating/restoring databases.

> My plan of attack will just be to slapcat the master and slapadd > it on the slave, then fire up slurpd. The slave is the one > that's showing the error - the master is fine. You should switch to using syncrepl.

-- -- 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/