Logbackのローテーション設定の妥当性を検証していた時に、不要ファイル（＝保存切れとなったアーカイブファイル）が消えなくて「なぜだ〜」となった時に調べた時のメモ。

NOTE:

検証時は、デバッグログを１つだけ出力するmainメソッドを作って、システム日付をずれして実行していました。

バージョン

Logback 1.2.3

なぜ不要ファイルが消えなかったのか！？

細かい条件は調べていませんが、実行時間が短命なスタンドアロンアプリ（＝ログ出力後にすぐにプロセスが終了するようなアプリ）の場合、ログファイルのローテーション後に行われるはずの不要ファイル（＝保存切れとなったアーカイブファイル）削除処理が行われる前のJVMが終了してしまうことがあるようです。

どうすればよい？

アプリ起動時に不要ファイル（＝保存切れとなったアーカイブファイル）を消す処理を呼び出すためのオプションを有効化しておくことで、次回の実行タイミングで不要なファイルを削除することができます。

起動時に不要ファイルを削除する処理を実行する際の設定例

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>/var/log/app-%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>7</maxHistory>
        <cleanHistoryOnStart>true</cleanHistoryOnStart> <!-- ★★★ ここを追加 ★★★ -->
    </rollingPolicy>
    <encoder>
        <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
        <charset>UTF-8</charset>
    </encoder>
</appender>

NOTE:

Webアプリケーションなどの常駐型のアプリケーションの場合は、よほどのことがない限りはローテーションタイミングで不要ファイルも削除されます（＝切り替え時にプロセスが終了する可能性が非常に低いため）。仮に運悪く削除されないことがあっても、次のローテーションの機会で削除されるので上記設定がなくても問題になることはないと思われます。

まとめ

おそらく・・・商用サービスで動くようなアプリでは cleanHistoryOnStart を指定しなくてもほとんど大丈夫でしょう。瞬殺で終わるようなバッチアプリ！？（瞬殺で終わるならバッチにしなくてええやん・・・という話はありそうだが・・）がある場合は、念のためにこのオプションを指定しておくとよいかもしれません。
あと・・・私のようにローテーションの動作確認する時はこのオプション入れておかないと「何故だ〜」と無駄な時間を過ごすことになるかもしれません。