2010-08-25 19 views
2

Parfois, lorsque je lance mon application Java, le logback refuse d'écrire quoi que ce soit dans mon fichier journal. Parfois, il refuse également de lancer le fichier journal à minuit (ou au premier événement de journalisation après minuit), ce qui entraîne la perte des événements de journalisation dans le vide. Quand je regarde mon fichier journal principal quand les journaux n'ont pas réussi à faire rouler le journal, il aura un temps comme 23:59, avec la date d'hier, et toutes les instructions de journalisation après cette heure seront irrémédiablement perdues. J'ai un fichier de configuration assez simple, et il semble correct. Il est certainement être correct, car il fonctionne la plupart du temps.Parfois, le journal n'écrit pas dans le fichier journal et, parfois, ne l'affiche pas

Voici mon fichier de configuration:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender"> 
    <!--See http://logback.qos.ch/manual/appenders.html#RollingFileAppender--> 
    <!--and http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy--> 
    <!--for further documentation--> 
    <append>true</append> 
    <File>aggregator.log</File> 
    <encoder> 
     <!-- was: %d{yyyy-MM-dd HH:mm:ss}%5p [%t] (%F:%L) - %msg%n --> 
     <pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] \(%class{25}:%line\) - %msg%n</pattern> 
    </encoder> 
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> 
     <!-- By setting the name to .gz here, we get free compression. --> 
     <fileNamePattern>aggregator.log.%d{yyyy-MM-dd}.gz</fileNamePattern> 
    </rollingPolicy> 
    </appender> 
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> 
    <encoder> 
     <pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level [%thread] \(%class{25}:%line\) - %msg%n</pattern> 
    </encoder> 
    </appender> 
    <root level="DEBUG"> 
    <appender-ref ref="file"/> 
    <appender-ref ref="console"/> 
    </root> 
</configuration> 

Malheureusement, je ne peux pas reproduire de manière fiable cette erreur, si le débogage est un peu difficile. Est-ce que quelqu'un pourrait me dire ce que je fais mal, ou quoi d'autre pourrait être le problème? Si c'est utile, je redirige STDOUT et STDERR vers/dev/null (je cours sur linux, btw).

+0

Je viens de mettre à jour à la dernière publication. J'espère que ça aide. –

Répondre

0

Il s'avère que cela avait très peu à voir avec le logback du tout. Le problème était que j'avais un fichier .policy qui ne spécifiait pas les permissions appropriées pour les applications. Les moments où je pensais avoir réussi à faire pivoter des fichiers étaient des moments où j'avais déplacé ou effacé les précédents à la main. J'ai résolu cela en m'assurant que le logback avait les permissions suffisantes pour faire tourner ses propres logs.

7

Pour déboguer le problème, utilisez <configuration debug="true"> et ne redirigez pas stdout. Logback imprimera des messages là-bas pendant qu'il analyse la configuration et quand quelque chose ne va pas.

+0

Je me rends compte que je peux le faire, mais comme je ne peux pas reproduire ce comportement, il est très difficile à résoudre, même avec toutes les informations. Mais, je vais essayer ... –

+0

J'ai couru avec le débogage et jette un coup d'oeil à la sortie, et le logback ne s'est pas plaint. C'était normal, car la configuration fonctionne bien la plupart du temps. –

+0

Lancez-le et attendez qu'il se casse. Ensuite, vous devriez voir une erreur sur stdout. –