Missed rollover during application down

[mstaudt]

Hi all, I have the following appender setup in my application that performs hourly rollover and compresses log files:

<appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
  ..
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <fileNamePattern>log.json.%d{yyyy-MM-dd-HH}.gz</fileNamePattern>
    <maxHistory>36</maxHistory>
    <totalSizeCap>1GB</totalSizeCap>
  </rollingPolicy>
</appender>

which produces files like these:

log.json.2026-04-14-08.gz
log.json.2026-04-14-09.gz
log.json.2026-04-14-10      <-- currently active file

this is working great except for the following scenario:

• Let's say the application is down (i.e. due to a deployment) from 10:58 to 11:02
• The rollover of the log.json.2026-04-14-10 file does not happen, so it's not getting compressed to .gz
• During next archive removal execution, this file is also not touched as it doesn't match the .gz file extension
• This leads to orphan files that slowly eat up disk space without any built-in removal from logback

Using cleanHistoryOnStart also doesn't help, as this only checks for .gz files as specified in the fileNamePattern.

I'm looking for advice on how to handle these cases, as I imagine this could be a thing affecting other applications as well. Thanks!

[lMysticl]

Use a stable active filename and reserve fileNamePattern for archives:

<appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
  <file>log.json</file>
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <fileNamePattern>log.json.%d{yyyy-MM-dd-HH}.gz</fileNamePattern>
    <maxHistory>36</maxHistory>
    <totalSizeCap>1GB</totalSizeCap>
  </rollingPolicy>
</appender>

Without <file>, the active filename is recalculated from the current period when the application starts, so the previous raw period file is no longer the active file to roll. With a fixed <file>, Logback decouples the active file from archive names, and the first logging event after restart can roll and compress the elapsed period correctly. The Logback manual explicitly notes that this layout remains correct even when rollover is triggered late: TimeBasedRollingPolicy.

cleanHistoryOnStart manages matching archives; it cannot repair the unmatched raw files produced by the original layout.

[ceki]

@mstaudt it seems that this problem has a relatively easy fix. Please convert this to an issue so that it can be tracked.

@lMysticl Thank you for your thoughtful explanation. The addition of a <file> element is indeed a valid workarond. However, one inconvenience of having a non-null <file> is that it has to be moved (a blocking operation) whereas with no <file> log files for each period are independent.

[ceki]

FYI, I created #1070

[ceki]

Fixed in release 1.6.5