K8s部署Spring应用启动时Logback滚动压缩任务中断致启动失败

该错误触发在Logback上下文初始化阶段，核心触发逻辑：

1. Logback加载SizeAndTimeBasedRollingPolicy时，会默认扫描配置的日志目录，检查是否存在未完成的历史压缩任务、待清理的超期归档文件
2. K8s环境中Pod重建/崩溃时，日志目录下经常残留上一个实例未完成压缩生成的.tmp临时文件，Logback会默认阻塞主线程等待这些不存在的压缩任务完成
3. 1.2.12版本以前的Logback对压缩等待阶段的线程中断信号没有容错处理，直接抛出IllegalStateException终止整个日志上下文初始化，连带导致Spring Boot启动失败

当前配置没有加任何启动容错参数，是触发该问题的直接配置层面原因。

按优先级从高到低选择：

方案1：补全滚动策略容错配置（无版本依赖，最推荐） #

修改FILE-JSON-LIBS appender下的rollingPolicy配置块，新增3个容错参数，修改后的完整滚动策略配置如下：

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
    <!-- daily rollover -->
    <fileNamePattern>
        ${LOG_DIR}/${dtlogname:-${ACTIVE_APP}}-${envname:-${ENV}}-libs-json-${HOSTNAME}.%d{yyyy-MM-dd}.%i.gz
    </fileNamePattern>
    <maxFileSize>1GB</maxFileSize>
    <totalSizeCap>10GB</totalSizeCap>
    <!-- keep 30 days worth of history -->
    <maxHistory>30</maxHistory>
    <!-- 新增容错配置 -->
    <cleanHistoryOnStart>true</cleanHistoryOnStart>
    <asyncCompression>true</asyncCompression>
    <maxWaitForCompressionJobs>0</maxWaitForCompressionJobs>
</rollingPolicy>

参数作用说明：

• cleanHistoryOnStart=true：启动时自动清理超期归档文件、残留的.tmp压缩临时文件，从根源避免等待不存在的压缩任务
• asyncCompression=true：所有日志压缩操作走独立异步线程池，不阻塞日志系统初始化主线程
• maxWaitForCompressionJobs=0：启动阶段不等待任何历史压缩任务完成，遇到残留未完成任务直接跳过，不会触发中断异常

方案2：升级Logback版本（长期方案） #

Logback 1.2.12及以上版本（Spring Boot 2.7.12+、3.x版本默认内置）已经修复该问题：启动阶段遇到压缩线程中断信号时仅打印WARN级别的告警日志，不会终止上下文初始化。
如果应用使用的Spring Boot版本低于2.7.12，可以直接在构建配置中强制指定Logback版本为1.2.12，无需修改日志配置即可规避启动失败问题。

方案3：K8s层面紧急止血（临时恢复用） #

如果需要紧急恢复业务、来不及发布新版本，可以修改工作负载的Pod配置，将日志目录挂载为emptyDir类型卷，Pod销毁时会自动清空目录内的残留文件，避免新启动实例扫描到无效临时文件。注意该方案会丢失容器本地存储的历史日志，仅适合临时应急，后续仍需通过应用层配置彻底修复。

配置修改完成后重启Pod，检查启动日志中无Logback configuration error detected相关报错，应用正常监听端口、输出启动日志即为修复生效。可手动在日志目录下放置后缀为.tmp的测试文件模拟残留压缩任务，重启Pod验证容错逻辑正常。

内容的提问来源于stack exchange，提问作者prateek jangid