Dépannage avec des fichiers journaux

Cette section décrit le dépannage de LiveCycle à l’aide des fichiers journaux.

Fichier journal LiveCycle

Par défaut, le fichier journal LiveCycle se trouve dans le répertoire [racine LiveCycle] et il est nommé log.txt. Ce fichier journal est utile pour l’analyse des défaillances de LiveCycle et peut être nécessaire lorsque vous contactez le service d’assistance aux entreprises Adobe.

Fichier journal de Configuration Manager

Par défaut, le fichier journal de Configuration Manager se trouve dans le répertoire [racine LiveCycle]\ConfigurationManager\log et peut être nommé lcm.0.log. Les fichiers journaux sont utiles pour l’analyse des défaillances de Configuration Manager et peuvent être nécessaires lorsque vous contactez le service de support aux entreprises d’Adobe.

Dépannage de votre serveur d’applications avec les fichiers journaux

Les informations figurant dans les fichiers journaux du serveur d’applications peuvent être utilisées pour faciliter le dépannage des problèmes que vous rencontrez avec votre implémentation de LiveCycle. Si les informations fournies sont insuffisantes pour résoudre le problème, activez la journalisation détaillée pour augmenter le nombre de données consignées. La journalisation détaillée ne doit être activée qu’à des fins de dépannage, car elle réduit les performances du système et monopolise l’espace disque pour les fichiers journaux.

Remarque : il est recommandé de faire appel au service de support aux entreprises d’Adobe pour résoudre des problèmes à l’aide des fichiers journaux détaillés.

Fichier journal de JBoss

Par défaut, les fichiers journaux JBoss sont nommés boot.log et server.log. Ils se trouvent à l’emplacement suivant :
  • Clé en main - [racine LiveCycle]\jboss\server\lc_turnkey\log

  • Manuel - [racine du serveur d’applications]\server\standard\log.

Les fichiers journaux sont utiles pour l’analyse des défaillances de JBoss Application Server et de l’amorçage de LiveCycle et peuvent être nécessaires lorsque vous contactez le service de support aux entreprises d’Adobe.

Si les fichiers journaux ne fournissent pas suffisamment d’informations pour vous aider à résoudre les problèmes, vous pouvez activer la journalisation en mode TRACE pour augmenter le nombre de détails en modifiant le fichier log4j.xml [racine du serveur d’applications]/conf.

Remarque : assurez-vous de sauvegarder le fichier log4j.xml dans le répertoire [racine du serveur d’applications]/conf avant de le modifier.

Pour activer la journalisation en mode TRACE dans JBoss

  1. Depuis une invite de commande, accédez au répertoire [racine du serveur d'applications]/conf.

  2. Modifiez le fichier de configuration log4j.xml dans un éditeur de texte.

  3. Recherchez l’enregistreur automatique <root> dans le fichier et modifiez-le comme suit :

            <root> 
                    <priority value="INFO" /> 
            <appender-ref ref="FILE" /> 
            </root>
  4. Avant l’enregistreur automatique <root>, saisissez le texte suivant :

            <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. Recherchez la chaîne <appender name= »FILE » dans le fichier et modifiez ou entrez la ligne suivante :

            <param name="Threadhold" value="DEBUG" />
  6. Recherchez la chaîne <!-- A size based file rolling appender dans le fichier et collez le texte suivant sur la ligne qui le suit :

            <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. Enregistrez le fichier log4j.xml, puis fermez-le.

Pour désactiver la journalisation en mode TRACE dans JBoss

  1. Depuis une invite de commande, accédez au répertoire [racine du serveur d’applications]/conf.

  2. Modifiez le fichier de configuration log4j.xml dans un éditeur de texte.

  3. Recherchez l’enregistreur automatique <root> dans le fichier et modifiez-le comme suit :

            <root> 
                <priority value="INFO" /> 
                <appender-ref ref="FILE" /> 
            </root>
  4. Avant l’enregistreur automatique <root>, entrez le texte suivant :

            <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. Recherchez la chaîne <appender name= »FILE » dans le fichier et modifiez-la ou entrez la ligne suivante :

            <param name="Threadhold" value="DEBUG" />
  6. Recherchez la chaîne <!-- A size based file rolling appender dans le fichier et collez le texte suivant sur la ligne qui le suit :

            <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. Enregistrez le fichier log4j.xml, puis fermez-le.

Fichier journal de WebLogic

Par défaut, le fichier journal de WebLogic réside dans le répertoire /var/log/httpd/error_log. Les fichiers journaux sont utiles pour l’analyse des défaillance de WebLogic Server et de l’amorçage de LiveCycle et peuvent être nécessaires lorsque vous contactez le service d’assistance aux entreprises d’Adobe.

Si le fichier journal ne fournit pas les informations suffisantes pour vous aider à résoudre les problèmes, vous pouvez définir le niveau de tracé dans le fichier journal afin d’augmenter la quantité de détails consignés. Pour ce faire, modifiez le paramètre LogLevel dans le fichier [racine du serveur d’applications]/conf/httpd.conf. LogLevel définit la quantité d’informations consignées par les messages d’erreur dans les journaux d’erreurs. Les valeurs de LogLevel (de la moins détaillée à la plus détaillée) sont emerg, alert, crit, error, warn, notice, info et debug. La valeur par défaut de LogLevel est warn.

Remarque : créez une copie de sauvegarde du fichier [racine du serveur d’applications]/conf/httpd.conf avant de le modifier.

Pour activer le niveau de journalisation debug dans WebLogic

  1. Depuis une invite de commande, accédez au répertoire [racine du serveur d’applications]/conf.

  2. Modifiez le fichier de configuration httpd.conf dans un éditeur de texte.

  3. Recherchez le texte LogLevel dans le fichier et modifiez-le comme suit :

        LogLevel debug

 Enregistrez le fichier httpd.conf, puis fermez-le.

Une fois que vous avez terminé le dépannage, répétez les étapes 1 à 4, mais modifiez la chaîne LogLevel en la remplaçant par warn.

Fichier journal de WebSphere

Par défaut, le fichier journal de WebSphere se trouve dans [racine du serveur d’applications]/logs/server1. Les fichiers journaux sont utiles pour l’analyse des défaillances de WebSphere Application Server et de l’amorçage de LiveCycle et peuvent être nécessaires lorsque vous contactez le service d’assistance aux entreprises d’Adobe.

Si les informations fournies sont insuffisantes pour résoudre les problèmes, activez le mode de journalisation TRACE dans la console d’administration WebSphere pour augmenter le nombre de données consignées.

Pour activer le mode de journalisation TRACE dans WebSphere

  1. Connectez-vous à la console d’administration WebSphere et, dans l’arborescence de navigation, cliquez sur Troubleshooting > Logs and Trace puis, dans la liste des serveurs, cliquez sur server1 et sur Change Log Detail Levels.

  2. Sélectionnez Enable Trace et, dans le champ Trace Specification, saisissez com.adobe.*=all=enabled:com.adobe.framework.UITools=all=disabled.

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

Affichage de la sortie système et des journaux d’erreurs JVM

Les journaux d’erreurs et la sortie système JVM constituent de précieux outils pour résoudre les problèmes que rencontre votre serveur.

Pour afficher la sortie système JVM et les journaux d’erreurs

  1. Connectez-vous à la console d’administration WebSphere et, dans l’arborescence de navigation, cliquez sur Troubleshooting > Logs and Trace.

  2. Cliquez sur le nom du serveur d’applications, puis sur JVM Logs.

  3. Cliquez sur l’onglet Runtime et, sous System.out (pour afficher le journal de sortie du système de la JVM) ou sur System.err (pour afficher le journal d’erreurs). Cliquez sur View. Si l’une des sélections n’est pas disponible, vous pouvez afficher le tout à partir de l’onglet Configuration en indiquant les noms de fichier SystemOut.log et SystemErr.log. Par défaut, les fichiers sont enregistrés à l’emplacement suivant :

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

Pour empêcher l’affichage des vidages Java pendant le déploiement des fichiers EAR ou lors du redémarrage du serveur

Assurez-vous que le paramètre JAVA_HOME_32 est défini comme variable d’environnement uniquement et ne figure pas dans PATH.

Pour éviter les messages d’erreur répétitifs « reindexImpl started » dans les journaux du serveur WebSphere

Une fois que Content Services est déployé, vous pouvez observer le message d’erreur suivant qui apparaît de manière répétitive dans SystemOut.log :

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

    Pour résoudre ce problème, procédez comme suit :

    1. Dans l’arborescence de navigation WebSphere, cliquez sur Servers > Server Types > WebSphere application servers.

    2. Cliquez sur le nom d’un serveur d’applications dans le volet de droite.

    3. Cliquez sur Troubleshooting > Change Log Level Details.

    4. Dans la liste Components, naviguez jusqu’au package org.alfresco.repo.node.index.IndexTransactionTracker.

    5. Cliquez sur le package org.alfresco.repo.node.index.IndexTransactionTracker et sélectionnez No Logging.

    6. Répétez les étapes 1 à 5 pour les onglets Configuration et Runtime et pour tous les nœuds de la grappe.

Pour empêcher la répétition des messages d’erreur « Failed job » en provenance du planificateur Quartz

Si vous utilisez le port SOAP pour l’un de vos services, vous pouvez rencontrer un problème qui provoque des messages répétitifs « Failed job » provenant du planificateur Quartz, dans le fichier journal WebSphere pour tous les nœuds de la grappe.

Ces messages d’erreur continuent à apparaître même après que le nœud traitant la demande a été arrêté et qu’un autre nœud a terminé le travail en attente.

Pour éviter ce problème, utilisez la console d’administration afin de modifier la configuration des journaux pour tous les nœuds de la grappe WebSphere. Définissez le niveau de journalisation pour les packages suivants sur severe :

  • org.quartz.impl.jdbcjobstore

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

Suppression du fichier journal de transaction du serveur d’applications

Si les solutions des composants ne se déploient pas pour une raison quelconque, le serveur d’applications qui héberge LiveCycle ne redémarre pas car il tente de récupérer ce qu’il interprète comme des transactions annulées, mais n’y parvient pas. Pour résoudre ce problème, repérez et supprimez le fichier journal de transaction du serveur d’applications, puis redémarrez ce dernier.