- Fresh Install of Domino 10.0.1 FP2 on CentOS 7
- Fresh Install of IBM Lotus Notes Traveler 10.0.1.1 Build 201901271808_20
HTTP starts, but only after Traveler fails with various errors including:
- WARNING: Xsp Initialization error – Could not load class or methods
- WARNING: XPages/Traveler/Rest Web Services will not run until this is resolved
- HTTP JVM: java.io.FileNotFoundException: /local/notesdata/domino/workspace/.config/rcpinstall.properties (Permission denied)
- HTTP JVM: java.io.FileNotFoundException: /local/notesdata/domino/workspace/logs/Viewer_Translations.js (No such file or directory)
- HTTP JVM: java.nio.file.NoSuchFileException: /local/notesdata/domino/workspace/logs/error-log-0.html.lck
- HTTP JVM: java.nio.file.NoSuchFileException: /local/notesdata/domino/workspace/logs/trace-log-0.html.lck
- HTTP JVM: at com.ibm.domino.http.bootstrap.BootstrapClassLoader.findClass(BootstrapClassLoader.java:79
Upon inspection of the Owner and Group of /local/notesdata/domino/workspace, it is discovered that root owns the folder instead of notes:
Changing the ownership (recursively) to notes:notes (when that is the account that was used to install Domino) resolves the issue:
After a number of intermittent and unexplainable issues with active user devices not syncing, I see that IBM has issued a fix in IBM Traveler 220.127.116.11 and later releases.
Once a user reports the issue, you can confirm by issuing the following console command:
tell traveler user "john smith/org"
The output will include:
Traveler: Monitoring of the database for changes is disabled.
The temporary workaround is to issue the following console command:
tell traveler push enable "john smith/org"
Now the “tell traveler user” command should return:
Traveler: Monitoring of the database for changes is enabled.
..and the user’s mobile device will begin to receive the backlog of messages again.
To resolve the issue install IBM Traveler 18.104.22.168 or later and cross your fingers.
LO91723: USERS STOP RECEIVING MAIL AFTER MAIL SERVER IS RESTARTED
Beginning with IBM Traveler 22.214.171.124, the NTS_DEFRAG_INTERVAL_DAYS= ini setting is no longer valid.
If the setting is still present in the Traveler server’s ini, you will see the following warning on the server console (and/or in the log) when Traveler starts:
Traveler: WARNING *system Unrecognized IBM Traveler parameter in notes.ini: NTS_DEFRAG_INTERVAL_DAYS
If the server was upgraded with the NTS_DEFRAG_INTERVAL_DAYS= in place, the upgrade process appears to transfer the previously set interval. The same result can be achieved by issuing: tell traveler dbmaint set interval 30
You can then verify the set interval using: tell traveler dbmaint show
Don’t forget to remove the NTS_DEFRAG_INTERVAL_DAYS= setting from your post-126.96.36.199 server’s ini.
In a standalone DB situation where you want to trigger Traveler database maintenance, you can issue the following command at the console: tell traveler DBMaint run
This will set the ini parameter NTS_DEFRAG_ONCE=1 which will trigger defrag at the next Traveler restart. The server will automatically remove the NTS_DEFRAG_ONCE=1 setting after the triggered defrag completes.
Again, in a standalone DB situation, you could automate regularly scheduled defrags to run by:
- Using the “tell traveler DBMaint set” commands to set the desired interval, time, day
- Creating a Program document that issues the server command, restart task traveler, just after the time set in the command above