The following is the minimum set of logs that you should gather:
Use the following table as a quick reference for stack trace commands. Sometimes it's useful to generate a stack trace from a core and save it to a file. Refer to the Tech Tip, "About Core Dumps", for using the pstack command. Also see the Tech Tip, "How To Analyze Core Dumps using GDB." For more information about the dbx command, contact ENOVIA Support. The Live Collaboration server will log error messages to the mxtrace.log and other log files, as described in "Server Diagnostics". The ENOVIA Live Collaboration Server uses a set of log files to maintain state information. These log files can be found by checking the rmireg.sh or rmireg.bat files, and locating the rmid daemon load line with the -log option, as shown below: $JAVA_PATH/rmid $JAVA_OPTIONS $JAVA_LIB -J$JAVA_SECURITY -port 1099 -log /opt/eMatrixRMI9052/logs/RMI1099 & These log files are not useful for diagnostic purposes, and you should delete all files from this directory. If multiple rmid processes have been started from the startup script (i.e., the RMI gateway is in use), then you should delete each set of logs. If a shutdown occurs, a file called the Java stack dump log is created. It is named hs_err_pidxxxx.log, where xxxx is the Process ID number of the process that shut down. These logs can be found in the same directory from which the ENOVIA Live Collaboration kernel loads, usually the SERVER_INSTALL path under PLATFORM\code\bin\. These logs are critical for reporting a shutdown-related problem to ENOVIA Live Collaboration, especially if no core is found. If the system has produced a core file for the shutdown (Unix-only, and the file is simply called core), this file will usually appear in the directory from which the ENOVIA Live Collaboration kernel was loaded. | |||||||||||||||||||||