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

[Stevo Slavic (JIRA)]

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

Stevo Slavic commented on LBCORE-188:
-------------------------------------

I was experiencing this behavior on both windows and linux, with zip archiver, but because of my mistake in configuration of ch.qos.logback.core.rolling.TimeBasedRollingPolicy's FileNamePattern. Pattern didn't include window index reference, and ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP was configured as timeBasedFileNamingAndTriggeringPolicy, so second time logback tried to create archive it would encounter situation where destination archive file already exists and it would leave .tmp file behind.

FileNamePattern was "baselogfilename.%d{yyyy-MM-dd}.log.zip", while it should have been "baselogfilename.%d{yyyy-MM-dd}.%i.log.zip"

> 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