Environment
Novell Access Manager 3.1 Access Gateway Service on SLES 11
Situation
Running the Access Gateway Serive (AGS) install on SLES 11 x64. The install appears to sit for a very long time without progress -- up to 5 minutes. The debug messages present on the console during this 6 minute hang was roughly here:
------------------
Local IP=134.216.178.50
Random ID= 8799049652805127
USER_MAGIC_FOLDER_4=/var/opt/novell/tomcat5/webapps
About to create reimport_ags.sh - Linux
USER_MAGIC_FOLDER_9=/opt/novell/devman/jcc/conf
About to create reimport.bat - Windows 2
USER_MAGIC_FOLDER_9=/opt/novell/devman/jcc/conf
Retrying Installables deferred in pass 0
Deferral retries done because:
There were no deferrals in the last pass.
RepositoryManager: repository successfully written to stable storage
RepositoryManager: repository successfully written to stable storage
The install log files do not include timestamps so we cannot identify what is going on exactly.
------------------
Local IP=134.216.178.50
Random ID= 8799049652805127
USER_MAGIC_FOLDER_4=/var/opt/novell/tomcat5/webapps
About to create reimport_ags.sh - Linux
USER_MAGIC_FOLDER_9=/opt/novell/devman/jcc/conf
About to create reimport.bat - Windows 2
USER_MAGIC_FOLDER_9=/opt/novell/devman/jcc/conf
Retrying Installables deferred in pass 0
Deferral retries done because:
There were no deferrals in the last pass.
RepositoryManager: repository successfully written to stable storage
RepositoryManager: repository successfully written to stable storage
The install log files do not include timestamps so we cannot identify what is going on exactly.
Resolution
Ignore the fact that the install status has not changed for up to 5 minutes.
Additional Information
We have debugged this code, which is very small, set up timers, and
tried to track it down without much luck. The generation of these
files should be done in seconds; however, we're finding that under the
right circumstances, the generation of these files can take up to 4-5
minutes per file.
All we are doing is request the certificate information from eDirectory and it just sits there doing nothing. We can't time that out neither so we're at the mercy of that code.
We have noticed that the problem is more prone to happen when running against an eDirectory running on a 64-bit Linux server. Occasionally, I've seen it happen on Windows, but it is mostly Linux.
All we are doing is request the certificate information from eDirectory and it just sits there doing nothing. We can't time that out neither so we're at the mercy of that code.
We have noticed that the problem is more prone to happen when running against an eDirectory running on a 64-bit Linux server. Occasionally, I've seen it happen on Windows, but it is mostly Linux.