When KIM is started, all the activity is recorded in the log files contained in the {{*<KIM_HOME>/log{*}}} folder. The web interface puts its messages to the servlet container's logs (for Apache Tomcat they are located in {{*<TOMCAT_HOME>/logs{*}}}). If you experience trouble running KIM, these logs should be your primary source for getting information about what happened. In case KIM crashes, has shutdown issues, or severe functional problems, you should increase the logging level of KIM in order to isolate the issue. You can control the amount of details in the KIM logs by modifying the configuration file {{*<KIM_HOME>/config/logback.xml{*}}}.
(i) For KIM versions up to 3.0 modify the [log4j|http://logging.apache.org/log4j/1.2/manual.html] file {{*<KIM_HOME>/config/log.prop{*}}}.
|| Log modes || Description ||
| [INFO|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#INFO] | The default KIM logging level |
| [TRACE|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#TRACE]\\ | The most detailed logging mode available. |
| [DEBUG|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#DEBUG]\\ | Designates fine-grained informational events that are most useful to debug an application. |
| [WARN|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#WARN]\\ | Designates potentially harmful situations. |
| [ERROR|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#ERROR]\\ | Designates error events that might still allow the application to continue running. |
| [FATAL|http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#FATAL]\\ | Records only errors of application crashes. |
For more information about logging options, please see the [log4j 1.2 documentation|http://logging.apache.org/log4j/1.2/manual.html].
{note}Using *DEBUG* or *TRACE* modes can sometimes lead to big logs with size of many gigabytes. We recommend that you use *DEBUG* mode only to collect more detailed information about your problem and then switch back to *INFO* mode.{note}
Sometimes the logs may not help to solve the problems you might experience with KIM. In that case, after you isolate a scenario reproducing the problem, please follow the procedure below to collect and send us the full logging information.
1. Stop KIM.
2. Enable *DEBUG* logging of KIM by changing the line
{code}@log4j.rootLogger=INFO, aAll, cAll@{code}
to
{code}@log4j.rootLogger=DEBUG, aAll, cAll@{code}
in the KIM section of *<KIM_HOME>/config/log.prop*
{note} Please keep in mind that KIM performance will be significantly reduced in *DEBUG* mode.{note}
3. Archive and then delete the contents of the {{<KIM_HOME>/log}} folder.
4. Open the servlet container log folder, archive and delete its content
5. Start KIM.
6. Execute the scenario leading to the problem.
7. Stop KIM.
8. Collect the following logs:
* The contents of the {{<KIM_HOME>/log}} folder.
* The console output of KIM.
{panel} *On Linux*, start KIM with {code}nohup ./kim start &{code}. This will put the console output in *<KIM_HOME>/bin/nohup.out* .{panel}
* The console output or any other scripts used in the tests - tools/populate, tools/rdf etc.
* The contents of the servlet container log folder.
9. Zip and send them to _[kim-discussion@ontotext.com|mailto:kim-discussion@ontotext.com]_.
...