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)
Running: openldap-client-2.3.37 openldap-server-2.3.37 db44-4.4.20.4 FreeBSD 6.1-RELEASE-p3
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 .
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?
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 .
On 14-Sep-07, at 12:18 PM, Howard Chu wrote:
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.
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.
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.
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.
On 14-Sep-07, at 7:41 PM, Howard Chu wrote:
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.
Right. I missed the note in the Administrators Guide about the gains of using LDIF.
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.
Good to know, thank you.
-- -- 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/
--On Friday, September 14, 2007 12:30 PM -0400 Jason Lixfeld jason+lists.openldap@lixfeld.ca wrote:
I had slurpd running,
There's your problem right there. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Howard Chu -
Jason Lixfeld -
Quanah Gibson-Mount