Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-1764

admin-backend.ldif can end up empty


    • Support Ticket IDs:


      It is possible for a replica server to end up with zero-length admin-backend.ldif and admin-backend.ldif.old files. When the server is restarted, it fails and shuts itself down immediately:

      [28/Jan/2015:21:13:06 -0800] category=CORE severity=NOTICE msgID=458891 msg=The Directory Server has sent an alert notification generated by class org.opends.server.core.DirectoryServer (alert type org.opends.server.DirectoryServerShutdown, alert ID 458893): The Directory Server has started the shutdown process. The shutdown was initiated by an instance of class org.opends.server.core.DirectoryServer and the reason provided for the shutdown was An error occurred while trying to start the Directory Server: CryptoManager failed to publish the instance-key-pair public-key-certificate entry in ADS: Failed to add entry "ds-cfg-key-id=955C6BA8A997530838CE7E7126DC73F8,cn=instance keys,cn=admin data" (id=262812)

      This has been observed to occur with several customers, and generally they all report that the disks have filled up.

      However, inspecting the LDIFBackend code I cannot see how - if the backend has entries - we could end up failing to write a complete LDIF file and not detect the problem. However we do ignore any exceptions thrown when we close() the file, which could be hiding a problem.

      I've not been able to reproduce this problem on OS X. It feels like it might be filesystem or OS-specific.

      But it seems to me that we could bulletproof our code somewhat.

      Firstly, we could check the length of the .ldif.new file is non-zero, and fail if the backend actually has entries. This seems like a reasonable sanity check.

      Secondly, we could check the length of .ldif file when reading, and try the .ldif.old file automatically if it is empty.




            • Assignee:
              cjr Chris Ridd
              cjr Chris Ridd
              QA Assignee:
              Ondrej Fuchsik
            • Votes:
              0 Vote for this issue
              4 Start watching this issue


              • Created: