|
When file compression is enabled and triggered (gz or zip) and the program exits before Logback can complete the compression, the full-sized tmp file and an incomplete archive are created.
Logback config:
{{<configuration debug="TRUE">
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>logs/info.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>logs/info.%d {yyyy-MM-dd}
.log.gz</fileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%date %level [%thread] %logger {40}
- %msg%n</pattern>
</encoder>
</appender>
<root level="DEBUG">
<appender-ref ref="FILE" />
</root>
</configuration>
}}
Output:
{{total 102448
rw-r
r
- 1 aselesse staff 52428800 3 Apr 11:23 info.log386225310397706.tmp
drwxr-xr-x 14 aselesse staff 476 4 Apr 11:23 ..
rw-r
r
- 1 aselesse staff 57 4 Apr 11:23 info.log
rw-r
r
- 1 aselesse staff 16394 4 Apr 11:23 info.2016-04-03.log.gz}}
I've included a sample minimal project that reproduces the bug. Basically, in the project, I have a script (creatively called reproduce-bug) that should replicate the situation I've described above. The script creates a 50 MB log file with random data, sets the modification time to yesterday, and runs an app (through Gradle) that appends to this log file. The app exits quickly, so Logback doesn't get a chance to finish compression.
A "workaround" for this issue is to make my program sleep until the compression ends.
Would it be feasible to keep the process alive until the Logback compression finishes somehow? Also, it might be worthwhile to add a note to the documentation to explain this caveat.
|