Troubleshooting with log files

This section describes how to troubleshoot LiveCycle using the log files.

LiveCycle log file

By default, the LiveCycle log file is located in the [LiveCycle root] directory and is named install.log. This log file is useful for LiveCycle failure analysis and may be required when dealing with Adobe Enterprise Support.

Configuration Manager log file

By default, the Configuration Manager log file is in [LiveCycle root]\ConfigurationManager\log and may be named lcm.0.log. The log files are useful for Configuration Manager failure analysis and may be required when dealing with Adobe Enterprise Support.

Troubleshooting your application server using log files

Information in the application server log files can be used to help troubleshoot problems you are experiencing with your LiveCycle implementation. If the log files do not provide enough information to help you troubleshoot problems, you can enable verbose logging to increase logging details. Verbose logging should be enabled only during troubleshooting; otherwise, it slows system performance and consumes additional disk space for log files.

Note: It is recommended that you work with Adobe Enterprise Support to troubleshoot problems when using verbose log files.

JBoss log file

By default, the JBoss log files are named boot.log and server.log located at:
  • Turnkey - [LiveCycle root]\jboss\server\lc_turnkey\log

  • Manual - [appserver root]\server\standard\log.

The log files are useful for JBoss Application Server and LiveCycle failure analysis, and may be required when dealing with Adobe Enterprise Support.

If the log files do not provide enough information to help you troubleshoot problems, you can enable TRACE logging to increase logging details by modifying the log4j.xml file in the [appserver root]/conf directory.

Note: Ensure that you back up the log4j.xml file in the [appserver root]/conf directory before you modify it.

To enable TRACE logging in JBoss:

  1. From a command prompt, go to the [appserver root]/conf directory.

  2. Edit the log4j.xml configuration file using a text editor.

  3. Locate the <root> logger element in the file and change it as follows:

            <root> 
                    <priority value="INFO" /> 
            <appender-ref ref="FILE" /> 
            </root>
  4. Above the <root> logger element, type the following text:

            <category name="org.jboss.ejb"> 
                <priority value="TRACE" class="org.jboss.logging.XLevel"/> 
                <!--Comment the line below if you want to disable tracing --> 
                <appender-ref ref="TRACE_FILE" /> 
                <appender-ref ref="FILE" /> 
            </category>
  5. Locate <appender name="FILE" in the file and change or enter the following line:

            <param name="Threadhold" value="DEBUG" />
  6. Locate <!-- A size based file rolling appender in the file and paste the appender in the line below:

            <appender name="TRACE_FILE"  
                class="org.jboss.logging.appender.RollingFileAppender"> 
                <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
                <param name="File" value="${jboss.server.home.dir}/log/trace.log"/> 
                <param name="Append" value="false"/> 
                <param name="MaxFileSize" value="5MB"/> 
                <param name="MaxBackupIndex" value="2"/> 
                <layout class="org.apache.log4j.PatternLayout"> 
                <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/> 
                </layout> 
            </appender>
  7. Save and close the log4j.xml file.

To disable TRACE logging in JBoss:

  1. From a command prompt, go to the [appserver root]/conf directory.

  2. Edit the log4j.xmlconfiguration file using a text editor.

  3. Locate the <root> logger element in the file and change it as follows:

            <root> 
                <priority value="INFO" /> 
                <appender-ref ref="FILE" /> 
            </root>
  4. Above the <root> logger element, enter the following text:

            <category name="org.jboss.ejb"> 
                <priority value="TRACE" class="org.jboss.logging.XLevel"/> 
                <!--Comment the line below if you want to disable tracing --> 
                <appender-ref ref="TRACE_FILE" /> 
                <appender-ref ref="FILE" /> 
            </category>
  5. Locate <appender name="FILE" in the file and change or enter the following line:

            <param name="Threadhold" value="DEBUG" />
  6. Locate <!-- A size based file rolling appender in the file and paste the appender in the line below:

            <appender name="TRACE_FILE" 
            class="org.jboss.logging.appender.RollingFileAppender"> 
                <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/> 
                <param name="File" value="${jboss.server.home.dir}/log/trace.log"/> 
                <param name="Append" value="false"/> 
                <param name="MaxFileSize" value="5MB"/> 
                <param name="MaxBackupIndex" value="2"/> 
                <layout class="org.apache.log4j.PatternLayout"> 
                <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/> 
                </layout> 
            </appender>
  7. Save and close the log4j.xml file.

WebLogic log file

By default, the WebLogic log file is located in /var/log/httpd/error_log. The log files are useful for WebLogic Server and LiveCycle bootstrapping failure analysis, and may be required when dealing with Adobe Enterprise Support.

If the log file does not provide enough information to help you troubleshoot problems, you can specify the level of tracing in the log file to increase logging details. To do this, modify the LogLevel parameter in the [appserver root]/conf/httpd.conf file. LogLevel sets how verbose the error messages in the error logs are. LogLevel can be set (from least verbose to most verbose) to emerg, alert, crit, error, warn, notice, info, or debug. The default LogLevel is warn.

Note: Ensure that you back up the [appserver root]/conf/httpd.conf file before you modify it.

To enable debug LogLevel in WebLogic:

  1. From a command prompt, navigate to the [appserver root]/conf directory.

  2. Edit the httpd.conf configuration file using a text editor.

  3. Locate the LogLevel in the file and change it as follows:

        LogLevel debug

 Save and close the httpd.conf file.

When you have completed troubleshooting, repeat steps 1 to 4 but change the LogLevel to warn.

WebSphere log file

By default, the WebSphere log file is located at [appserver root]/logs/server1. The log files are useful for WebSphere Application Server and LiveCycle bootstrapping failure analysis, and may be required when dealing with Adobe Enterprise Support.

If the log files do not provide enough information to help you troubleshoot problems, in the WebSphere Administrative Console, you can enable TRACE logging to increase logging details.

To enable TRACE in WebSphere:

  1. Log in to WebSphere Administrative Console and, in the navigation tree, click Troubleshooting > Logs and Trace and, in the list of servers, click server1, and then click Change Log Detail Levels.

  2. Select Enable Trace and, in the Trace Specification box, type com.adobe.*=all=enabled:com.adobe.framework.UITools=all=disabled.

        [appserver root]/profiles/[profile_name]/logs/[server name]

Viewing the JVM system output and error logs

The JVM system output and error logs are valuable tools for troubleshooting problems with your server.

To view the JVM system output and error logs:

  1. Log in to WebSphere Administrative Console and, in the navigation tree, click Troubleshooting > Logs and Trace.

  2. Click the name of the application server, and then click JVM Logs.

  3. Click the Runtime tab and, under either System.out (to view the JVM system output log) or System.err (to view the error log). click View. If any of the selections are unavailable, you can view them from the Configuration tab by specifying the SystemOut.log and SystemErr.log file names. By default the files are located in the following location:

        [appserver root]/profiles/[profile_name]/logs/[server name]

To prevent Java core dumps from appearing during EAR deployment or when you restart the server:

Ensure that JAVA_HOME_32 is set only as an environment variable and is not included in the PATH.

To prevent repetitive "reindexImpl started" error messages in the WebSphere server logs:

After Content Services is deployed, you may observe the following error message appearing repetitively in SystemOut.log:

  • IndexTransact I org.alfresco.repo.node.index.IndexTransactionTracker reindexImpl reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@290c290c

    To resolve the issue, follow these steps:

    1. In the WebSphere navigation tree, click Servers > Server Types > Websphere application servers.

    2. Click an application server listed in the right pane.

    3. Click Troubleshooting > Change Log Level Details.

    4. In the Components list, navigate to the org.alfresco.repo.node.index.IndexTransactionTracker package.

    5. Click the org.alfresco.repo.node.index.IndexTransactionTracker package and select No Logging.

    6. Repeat steps 1-5 for the Configuration and Runtime tabs, and for all nodes in the cluster.

To prevent repetitive “Failed job” error messages originating from the Quartz scheduler:

If you are using the SOAP port for any of your services, you may encounter an issue that causes repetitive “Failed job” error messages, originating from the Quartz scheduler, to appear in the WebSphere log file for all nodes in the cluster.

These error messages continue to appear even after the node servicing the request has been shut down and another node has completed the pending job.

To avoid this issue, use the admin console to change the log configuration for all nodes in the WebSphere cluster. Set the log level for the following packages to severe:

  • org.quartz.impl.jdbcjobstore

  • com.adobe.idp.scheduler.jobstore.DSCJobStoreTX

Deleting the application server transaction log file

If the component solutions fail to deploy for any reason, the application server that hosts LiveCycle does not restart because it attempts to recover what it interprets as rolled back transactions but fails to do so. To resolve this issue, locate and delete the application server transaction log file and restart the application server.

// Ethnio survey code removed