[logback-dev] [JIRA] Commented: (LBCORE-188) Log Rotation/Gzip process leaving .tmp files behind

[Ceki Gulcu (JIRA)]

    [ http://jira.qos.ch/browse/LBCORE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12309#action_12309 ] 

Ceki Gulcu commented on LBCORE-188:
-----------------------------------

Benoit, with which version of logback are you observing this issue?


> Log Rotation/Gzip process leaving .tmp files behind
> ---------------------------------------------------
>
>                 Key: LBCORE-188
>                 URL: http://jira.qos.ch/browse/LBCORE-188
>             Project: logback-core
>          Issue Type: Bug
>          Components: Rolling
>    Affects Versions: 0.9.26
>            Reporter: Bert B-L
>            Assignee: Ceki Gulcu
>
> We are seeing logback leave .tmp files behind in the log directory, presumably due to a hiccup during log rotation or gzip.
> Size
> 2365956     Dec 11 00:00 statsreceiver.log.2010-12-10.gz
> 2679618     Dec 12 00:01 statsreceiver.log.2010-12-11.gz
> 9190879942  Dec 12 04:00 statsreceiver-debug.log23124507802228260.tmp
> 2542799     Dec 13 00:00 statsreceiver.log.2010-12-12.gz
> 9137740366  Dec 13 04:00 statsreceiver-debug.log23210907242250260.tmp
> 543937393   Dec 13 20:07 statsreceiver-debug.log.2010-12-13_19:00.gz
> 548781049   Dec 13 22:07 statsreceiver-debug.log.2010-12-13_21:00.gz
> 2284216     Dec 14 00:00 statsreceiver.log.2010-12-13.gz
> 8127562     Dec 15 00:00 statsreceiver.log.2010-12-14.gz
> 19067117496 Dec 15 13:00 statsreceiver-debug.log23416102512001260.tmp
> 18177324477 Dec 15 16:00 statsreceiver-debug.log23426920509229260.tmp
> 2257423     Dec 15 23:00 statsreceiver-debug.log.2010-12-15_22:00.gz
> The logback jar versions are:
>   WEB-INF/lib/logback-classic-0.9.26.jar
>   WEB-INF/lib/logback-core-0.9.26.jar
> There is only a single application writing to those files, though it is conceivable that the .tmp droppings correlate to restarts of that application.
> If this is expected on application restarts, could logback start gzip'ing them again when it comes back?
> Here is the logback.xml file:
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration scan="true" scanPeriod="60 seconds">
>   <appender name="FILE_WARN" class="ch.qos.logback.core.rolling.RollingFileAppender">
>     <file>${logdir:-.}/${prog:-unknown}.log</file>
>     <append>true</append>
>     
>     <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
>       <level>warn</level>
>     </filter>
>     
>     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>       <fileNamePattern>${logdir:-.}/${prog:-unknown}.log.%d{yyyy-MM-dd}.gz</fileNamePattern>
>       <maxHistory>7</maxHistory>
>     </rollingPolicy>
>      <encoder>
>         <pattern>%-30(%d{yyyy-MM-dd HH:mm:ss} %.-1level :) %m Context:[%X{GTNDC_INFO}]%n</pattern>
>      </encoder>
>   </appender>
>   <appender name="FILE_DEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender">
>     <file>${logdir:-.}/${prog:-unknown}-debug.log</file>
>     <append>true</append>
>     
>     <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
>       <level>debug</level>
>     </filter>
>     
>     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>       <fileNamePattern>${logdir:-.}/${prog:-unknown}-debug.log.%d{yyyy-MM-dd_HH:00}.gz</fileNamePattern>
>       <maxHistory>36</maxHistory>
>     </rollingPolicy>
>      <encoder>
>         <pattern>%-60(%d{yyyy-MM-dd HH:mm:ss} [%thread] %.-1level :) %m Context:[%X{GTNDC_INFO}]%n</pattern>
>      </encoder>
>   </appender>
> <logger name="org.apache.directory" level="WARN"/>
> <root><level value="debug"/>
>     <appender-ref ref="FILE_WARN"/>
>     <appender-ref ref="FILE_DEBUG"/>
> </root>
> </configuration>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira