Fehler mithilfe von Protokolldateien beheben

In diesem Abschnitt wird beschrieben, wie Sie Fehler in LiveCycle mithilfe der Protokolldateien beheben.

LiveCycle-Protokolldatei

Standardmäßig befindet sich die LiveCycle-Protokolldatei im [LiveCycle-Stammordner] und heißt „install.log“. Diese Protokolldatei ist bei der Fehleranalyse in LiveCycle nützlich und wird eventuell vom Adobe Enterprise-Support benötigt.

Configuration Manager-Protokolldatei

Standardmäßig befindet sich die Configuration Manager-Protokolldatei im Ordner „[LiveCycle-Stammordner]\ConfigurationManager\log“ und heißt „lcm.0.log“ (oder ähnlich). Die Protokolldateien sind bei der Fehleranalyse in Configuration Manager nützlich und werden eventuell vom Adobe Enterprise-Support benötigt.

Fehlerbehebung beim Anwendungsserver mithilfe der Protokolldateien

Sie können die Informationen in den Protokolldateien des Anwendungsservers verwenden, um Probleme mit Ihrer LiveCycle-Implementierung zu beheben. Falls die Protokolldateien nicht genügend Informationen für die Fehlerbehebung bereitstellen, können Sie die ausführliche Protokollierung aktivieren, damit mehr Details protokolliert werden. Die ausführliche Protokollierung sollte nur bei der Fehlerbehebung aktiviert werden, da ansonsten die Systemleistung verringert und zusätzlicher Speicherplatz für Protokolldateien belegt wird.

Hinweis: Sie sollten sich an den Adobe Enterprise-Support wenden, um Probleme mithilfe ausführlicher Protokolldateien zu beheben.

JBoss-Protokolldatei

Standardmäßig lauten die Namen der JBoss-Protokolldateien „boot.log“ und „server.log“ und befinden sich an folgendem Speicherort:
  • Turnkey – [LiveCycle-Stammordner]\jboss\server\lc_turnkey\log

  • Manuell – [Anwendungsserver-Stammordner]\server\standard\log

Die Protokolldateien sind bei der Fehleranalyse für den JBoss Application Server und LiveCycle nützlich und werden eventuell vom Adobe Enterprise-Support benötigt.

Falls die Protokolldateien nicht genügend Informationen für die Fehlerbehebung bereitstellen, können Sie die TRACE-Protokollierung aktivieren, damit mehr Details protokolliert werden. Dazu müssen Sie die Datei „log4j.xml“ im Ordner „[Anwendungsserver-Stammordner]/conf“ bearbeiten.

Hinweis: Stellen Sie sicher, dass Sie die Datei „log4j.xml“ im Ordner [Anwendungsserver-Stammordner] sichern, bevor Sie sie ändern.

Aktivieren der TRACE-Protokollierung in JBoss:

  1. Wechseln Sie an einer Eingabeaufforderung zum Ordner „[Anwendungsserver-Stammordner]/conf“.

  2. Bearbeiten Sie die Konfigurationsdatei log4j.xml mit einem Texteditor.

  3. Suchen Sie in der Datei das Protokollierungselement <root> und ändern Sie es folgendermaßen:

            <root> 
                    <priority value="INFO" /> 
            <appender-ref ref="FILE" /> 
            </root>
  4. Geben Sie oberhalb des Protokollierungselements <root> den folgenden Text ein:

            <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. Suchen Sie in der Datei den Eintrag <appender name="FILE" und ändern Sie die folgende Zeile bzw. geben Sie sie ein:

            <param name="Threadhold" value="DEBUG" />
  6. Suchen Sie <!-- A size based file rolling appender in der Datei und fügen Sie den Appender in die nachfolgende Zeile ein:

            <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. Speichern und schließen Sie die Datei log4j.xml.

Deaktivieren der TRACE-Protokollierung in JBoss:

  1. Wechseln Sie an einer Eingabeaufforderung zum Ordner „[Anwendungsserver-Stammordner]/conf“.

  2. Bearbeiten Sie die Konfigurationsdatei log4j.xml mit einem Texteditor.

  3. Suchen Sie in der Datei das Protokollierungselement <root> und ändern Sie es folgendermaßen:

            <root> 
                <priority value="INFO" /> 
                <appender-ref ref="FILE" /> 
            </root>
  4. Geben Sie oberhalb des Protokollierungselements <root> den folgenden Text ein:

            <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. Suchen Sie in der Datei den Eintrag <appender name="FILE" und ändern Sie die folgende Zeile bzw. geben Sie sie ein:

            <param name="Threadhold" value="DEBUG" />
  6. Suchen Sie <!-- A size based file rolling appender in der Datei und fügen Sie den Appender in die nachfolgende Zeile ein:

            <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. Speichern und schließen Sie die Datei log4j.xml.

WebLogic-Protokolldatei

Standardmäßig befindet sich die WebLogic-Protokolldatei im Ordner /var/log/httpd/error_log. Die Protokolldateien sind bei der Bootstrapping-Fehleranalyse für den WebLogic-Server und für LiveCycle nützlich und werden eventuell vom Adobe Enterprise-Support benötigt.

Falls die Protokolldatei nicht genügend Informationen für die Fehlerbehebung bereitstellt, können Sie die Ablaufverfolgungsstufe in der Protokolldatei angeben, damit mehr Details protokolliert werden. Dazu ändern Sie den Parameter LogLevel in der Datei „[Anwendungsserver-Stammordner]/conf/httpd.conf“. LogLevel bestimmt, wie ausführlich die Fehlermeldungen in den Fehlerprotokollen sind. Für LogLevel gibt es folgende mögliche Werte (von der geringsten zur höchsten Ausführlichkeit): emerg, alert, crit, error, warn, notice, info und debug. Der Standardwert für LogLevel ist warn.

Hinweis: Erstellen Sie unbedingt eine Sicherungskopie der Datei „[Anwendungsserver-Stammordner]/conf/httpd.conf“, bevor Sie sie ändern.

Aktivieren des LogLevel-Werts „debug“ in WebLogic:

  1. Wechseln Sie an einer Eingabeaufforderung zum Ordner „[Anwendungsserver-Stammordner]/conf“.

  2. Bearbeiten Sie die Konfigurationsdatei httpd.conf mit einem Texteditor.

  3. Suchen Sie in der Datei den Eintrag LogLevel und ändern Sie ihn folgendermaßen:

        LogLevel debug

 Speichern und schließen Sie die Datei httpd.conf.

Wenn Sie die Fehlerbehebung abgeschlossen haben, wiederholen Sie die Schritte 1 bis 4, ändern dabei den LogLevel-Wert jedoch in warn.

WebSphere-Protokolldatei

Standardmäßig befindet sich die WebSphere-Protokolldatei in „[Anwendungsserver-Stammordner]/logs/server1“. Die Protokolldateien sind bei der Bootstrapping-Fehleranalyse für den WebSphere-Anwendungsserver und LiveCycle nützlich und werden eventuell vom Adobe Enterprise-Support benötigt.

Falls die Protokolldateien nicht genügend Informationen für die Fehlerbehebung bereitstellen, können Sie in der Verwaltungskonsole von WebSphere die TRACE-Protokollierung aktivieren, damit mehr Details protokolliert werden.

Aktivieren der TRACE-Protokollierung in WebSphere:

  1. Melden Sie sich an der WebSphere-Verwaltungskonsole an und klicken Sie in der Navigationsstruktur auf Troubleshooting > Logs and Trace. Klicken Sie in der Liste der Server auf server1 und dann auf Change Log Detail Levels.

  2. Wählen Sie Enable Trace aus und geben Sie in das Feld Trace Specification den folgenden Text ein: com.adobe.*=all=enabled:com.adobe.framework.UITools=all=disabled.

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

JVM-Systemausgabe- und Fehlerprotokolle anzeigen

Die JVM-Systemausgabe- und Fehlerprotokolle sind wichtige Hilfsmittel bei der Diagnose von Serverstörungen.

Anzeigen der JVM-Systemausgabe- und Fehlerprotokolle:

  1. Melden Sie sich bei der Verwaltungskonsole von WebSphere an und klicken Sie in der Navigationsstruktur auf Troubleshooting > Logs and Trace.

  2. Klicken Sie auf den Namen des Anwendungsservers und anschließend auf JVM Logs.

  3. Klicken Sie auf die Registerkarte Runtime und klicken Sie entweder unter „System.out“ (zum Anzeigen des JVM-Systemausgabeprotokolls) oder unter „System.err“ (zum Anzeigen des Fehlerprotokolls), auf View. Wenn diese Wahlmöglichkeiten nicht zur Verfügung stehen, können Sie die Protokolle über die Registerkarte Configuration anzeigen, indem Sie die Dateinamen „SystemOut.log“ und „SystemErr.log“ angeben. Der Standardspeicherort der Dateien lautet wie folgt:

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

So verhindern Sie das Auftreten von Java-Core-Dumps während der EAR-Bereitstellung oder beim Neustart des Servers:

Stellen Sie sicher, dass JAVA_HOME_32 nur als Umgebungsvariable festgelegt ist und nicht im PFAD enthalten ist.

So verhindern Sie das wiederholte Auftreten von „reindexImpl started“-Fehlermeldungen in den WebSphere-Serverprotokollen:

Nach der Content Services-Bereitstellung kann es vorkommen, dass die folgende Fehlermeldung in „SystemOut.log“ wiederholt vorkommt:

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

    Um dieses Problem zu beheben, führen Sie die folgenden Schritte aus:

    1. Klicken Sie in der WebSphere-Navigationsstruktur auf Servers > Server Types > Websphere application servers.

    2. Klicken Sie im rechten Bereich auf einen der Anwendungsserver.

    3. Klicken Sie auf Troubleshooting > Change Log Level Details.

    4. Wechseln Sie in der Liste Components zum Paket org.alfresco.repo.node.index.IndexTransactionTracker.

    5. Klicken Sie auf das Paket org.alfresco.repo.node.index.IndexTransactionTracker und wählen Sie No Logging.

    6. Wiederholen Sie die Schritte 1 bis 5 für die Registerkarten Configuration und Runtime sowie für alle Knoten im Cluster.

So verhindern Sie wiederholte „Failed job“-Fehlermeldungen, die vom Quartz Scheduler stammen:

Wenn Sie den SOAP-Anschluss für einen der Dienste verwenden, kann ein Problem auftreten, das zu wiederholten „Failed job“-Fehlermeldungen führt, die vom Quartz Scheduler stammen und in der WebSphere-Protokolldatei für alle Knoten im Cluster angezeigt werden.

Diese Fehlermeldungen treten auch noch auf, nachdem der Knoten, der die Anforderung erfüllt hat, heruntergefahren wurde und ein anderer Knoten den Auftrag abgeschlossen hat.

Um dieses Problem zu vermeiden, ändern Sie mithilfe der Verwaltungskonsole die Protokollkonfiguration für alle Knoten im WebSphere-Cluster. Legen Sie die Protokollierungsstufe für die folgenden Pakete auf schwerwiegend fest:

  • org.quartz.impl.jdbcjobstore

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

Transaktionsprotokolldatei des Anwendungsservers löschen

Wenn die Bereitstellung der Lösungskomponenten aus irgendeinem Grund fehlschlägt, wird der Anwendungsserver, der als Host für LiveCycle dient, nicht neu gestartet, da er versucht, die für ihn vermeintlichen rückgängig gemachten Transaktionen wiederherzustellen, was aber fehlschlägt. Um dieses Problem zu beheben, suchen und löschen Sie die Transaktionsprotokolldatei des Anwendungsservers und starten den Anwendungsserver neu.