Posting this hoping to help others, as I could find very little
information myself when I went searching for solutions.

We were seeing higher than normal max ring delta on Sunday morning, so I
logged in to check things out. I saw some 625 errors to/from the master;
in the past sometimes an ndsd restart has helped to clear/reset the
connections so I tried that. ndsd did not properly restart there,
though, and this message was written into the ndsd.log:

FATAL: Transaction ID has exceeded the allowed limit of 4294959104
(0xffffe000). Run local database repair
The local agent could not be opened - failed, abort transaction (-6030)

Uh oh.

Google pointed me to -- eDirectory
"Transaction ID" Warning. I opened an SR and waited for Support to
contact me, as I saw in the TID that ndsrepair should be run, but that
Tech Support might need to do some manual editing as well.

It was determined to try running the ndsrepair as listed in the TID, so
we kicked that off around 1:45 pm on Sunday.

Helpful tips:

- Do the ndsrepair in a screen session on the server you're repairing
so you don't have to worry about some kind of network outage etc
interfering/interrupting the process
- Ensure you have as much as 3x the DIB set size in free disk.
ndsrepair showed that warning to me as it was starting. Fortunately we
could dynamically add disk to our VM, otherwise we would have run out of
space during the repair and I'm sure that would not be A Good Thing.
- Our DIB set is about 37 GB in size. The repair process moved from
Phase 1 to Phase 2 in about 45 minutes, and then sat in Phase 2 until
5:30 this morning (~40 hours), when it failed. I don't know how quickly
it progressed through the remaining steps (Phase 3 until error/halt).
The complete ndsrepair command output was:

$ sudo ndsrepair -R -i no -t no -r no -v no -c no

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf:
Repair utility for NetIQ eDirectory 8.8 - 8.8 SP8 v20806.02
DS Version 20806.06 Tree name:
Server name:

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 271648 bytes.

Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Repairing Directory On Server takahe
Start: Sunday, March 06, 2016 01:45:15 PM Local Time
WARNING: Repair may require more disk space than the available disk
space for this operation.
** All disk amounts are approximations **
Disk space currently available: 34563 MB
->DSRepair may need to use: 136359 MB
->Disk space remaining after operation: 34563 MB

Current transaction ID is 4294959131 (0xffffe01b). Allowed limit of
transaction is 4294959104 (0xffffe000)
Waiting for Directory Services to release the local database files
Please Wait...
DS Files Are Locked
Repairing Directory On Server
Physical Rebuild - phase 1
Physical Rebuild - phase 2
Physical Rebuild - phase 3
Repairing Directory On Server
Temporary DIB set replacing NDS working DIB set.
Waiting for Directory Services to release the local database files
Please Wait...
DS Files Are Locked
Unlocking local database files
Please Wait...
Waiting for Directory Services to release the local database files
Please Wait...
DS Files Are Locked
Waiting for Directory Services to release the local database files
Please Wait...
DS Files Are Locked
ERROR: Unable to initialize schema cache. Error: -6030
NOTICE: Unable to update repair status. Error: -663

Repair process aborted
Unlocking local database files
Please Wait...
Could not open the Directory Services Database, the repair procedure was
not successful. Try running the repair again, or uninstall this server
from the Directory Services tree and re-install it.
Total errors: 0

Again, uh oh. As you might have noticed, our Transaction ID
(4294959131) had actually somehow gotten above the maximum (4294959104).
There was no explanation offered from Support as to how that might have

I got back in touch with Support this morning, and they gave us a new
tool to use: fixtransid. It's one of those "use only when Support gives
it to you" deals. The command for that was

sudo ./fixtransid /var/opt/novell/eDirectory/data/dib/nds.db
-sr/var/opt/novell/eDirectory/data/dib -p

and it gave a nice interactive display of what it was doing (screen grab


If only ndsrepair would be so helpful about telling you what it's
done/what's left to do.

It took about 10 minutes for fixtransid to rip through the entire DIB
set and make a new copy of the nds.* files in the temp NEWDIB directory.
This resets the transaction ID effectively to zero. Once we copied those
new nds.* files back into the normal DIB directory, ndsd started right

Support also said that the TID I referenced was a bit out of date, and
that the fixtransid tool is the better way to do things these days. So
if you call for this in the future, mentioning fixtransid will save you
potentially days of time!

Also to mitigate the problem in the future, Support said they are
working on making FLAIM 64-bit so the transaction IDs can be much
larger. And enhancements to ndsrepair are coming at some point which
will make fixing this particular problem easier as well.

Again, I hope this provides some helpful information for anyone else
running into this problem in the future. If there is any specific
substep that might be helpful to elaborate on, I'm happy to try and do
that, but I think this is a pretty complete summary.


|Filename: fixtransid-running.jpg |
|Download: |

brucetimberlake's Profile:
View this thread: