Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...


Daniel Nashed

Preventing wrong server time and "time too far in the future"

Daniel Nashed – 20 July 2012 09:49:44

"time too far in the future" beside database corruptions this problem is one of the most critical issues you can run into.

- Database modified date is in the future
- All new documents have created date in the future based on this value (because time in a database never goes backward)
- Replication history is in future --> issues with replication
- View/Folder update time is in future --> index might not be updated

Not all issues can be completely reverted in an easy way.
You might be able to fix most of it by pulling a new replica.
But even that might not resolve all issues.

We had this issue again at a customer because of a wrong BIOS time after restart.
So I am finally looking into the new Domino 8 functionality to prevent servers from re-starting after a certain time has passed.

Domino keeps track of the time of the server in the notes.ini in via LAST_DOMINO_TIME (example: LAST_DOMINO_TIME=004EF4F1C1257A2E)
You can specify a time interval to prevent a server from starting if it was down for more than this time.

There are two notes.ini parameters involved:

Restart_Time_Interval=3600 (in seconds, smallest value is 300 seconds according to a TN)

I would set this parameter to at least 24 hours or maybe 48 hours just to be on the save side.

If the interval has been reached the server will not start and you will not see any log message about that.
The only hint is a new notes.ini entry like this

LAST_DOMINO_TIME_ABORT=16.07.2012 09:56:49 Startup aborted: Excess restart time interval.

will be added to the notes.ini

-- Daniel


1Patrick Tippner  20.07.2012 13:57:34  Preventing wrong server time and time too far in the future

Hi Daniel!

This is a very interesting article that will probably help to avoid lots of trouble!

Since we are already talking about fault-prevention:

I encountered another very unpleasant situtation a few days ago, when i expanded all the nested groups in our domino directory using some self-written lotus script code. The problem was, that the resulting field size of the members-field exceeded the dreaded 32K limit for some of those groups. Fortunately, only four groups were affected. There were error messages on the console showing replication problems regarding those documents, so i could easily track them down using the NoteID. Then, using ScanEZ, I searched and deleted the affected documents without creating a deletion stub, so they could replicate back into the database from another server. Now i'm wondering if there is some smart way to avoid saving documents in case that a fields' size, or even the document as a whole has exceeded the size limit?

2Daniel Nashed  20.07.2012 14:54:07  Preventing wrong server time and "time too far in the future"

@Patrick, I am not aware of any way to prevent this. normally I would expect that the document would not be written and an error would occur.

but it sounds like Domino is not handling this correctly at least in some cases. too large groups are an issue in general.

What I would do if you have some quite large groups (before you run into trouble) build a view containing the size of the "Members" field.

In general it is a good idea to keep groups small and also the usernames list for a user small. Long time ago I wrote a tool to generate the user-names list for all users and generate an alert when a size-limit is reached.

In your special case the script might have caused that no checking of the group size happened but on low level side storage of a document with this summary data size should have stopped.

-- Daniel

3Pravin  18.11.2014 7:50:54  Preventing wrong server time and time too far in the future

We have upgrade the domino server 9.x to Domino server 9.x FP2 but the server build number is showing older one and when i checked it in adminp i got the "time is to far", please suggest ehat need to be do...



    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]