Thanks for the reply Rich. It actually looks like we've got x86 and x64 builds of db4
on that server. I share this server with another team so I'll ask around who installed
what. I think the actual problem ended up being on-disk data corruption. There were a few
other signs of the disk heading south and things have cleared up since resolving them.
As for the documentation URL that references that script:
On 4/4/08 7:34 AM, "Rich Megginson" <rmeggins(a)redhat.com> wrote:
Richard Hesse wrote:
Scenario: two FDS 1.1 servers in a multi-master setup. Working fine
months without a hiccup (except to upgrade from 1.04) then replication
suddenly stops working. Checking the logs, I see this:
[03/Apr/2008:23:44:00 +0000] NSMMReplicationPlugin - changelog program -
agmt="cn=MM aa0-006-8.u.powerset.com" (aa0-006-8:636): Failed to retrieve
change with CSN 47f5710d000000010000; db error - -30999 DB_BUFFER_SMALL:
User memory too small for return value
How should I go about troubleshooting this? Searching for replication
conflicts didn't yield anything useful.
It looks as though it's attempting
to read something from the changelog
database, but it got the size wrong:
The DBcursor->get method may fail and return one of the following
The requested item could not be returned due to undersized buffer.
What version of db do you have on your system? i.e. rpm -qi db4
32-bit or 64-bit?
I'm not sure, but it looks as though the code is perhaps expecting bdb
to return ENOMEM in this case, and perhaps the bdb api has changed to
return DB_BUFFER_SMALL instead for this case?
I tried running template-cl-dump.pl
like the documentation suggested,
Which documentation? That needs to be updated.
but I couldn't find it anywhere in
/usr/share/dirsrv/script-templates (FC6 system).
Fedora-directory-users mailing list