`evaluateOnStartup="true"` saves logs under wrong file names after missing scheduled roll

Abierto
  • ¿Algo no está bien?
#4,449 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #4450 de @GChuf — cerrado sin fusionar

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
java
Área
backend

Línea de trabajo

The bug is in how CronTriggeringPolicy with evaluateOnStartup computes the rollover filename; the debug log shows RollingFileManager running a synchronous FileRenameAction with the current minute instead of the file's own period. Start by tracing the startup evaluation path from CronTriggeringPolicy into RollingFileManager. Done means a missed rollover archives under the file's own period name and a test with a missed schedule covers it. Pull request #4450 is already open against this issue, so check it before starting.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

appenders:Rolling bug priority: P1 waiting-for-maintainer

Description

CronTriggeringPolicy with evaluateOnStartup="true" archives a file from an earlier period under the current period's filename when a scheduled rollover was missed (e.g. the application was offline at the previous fire time). The next scheduled rollover archives under the same name and overwrites that archive, losing log data.

In essence - the filename is wrong and log data can be lost.

Configuration

Version: 2.26.1

Operating system: Ubuntu 22

JDK: openjdk version "17.0.20.1"

Logs

# Restart at 12:50:49: file from 12:48:26, rollovers at 12:49 and 12:50 were missed
2026-11-02T11:50:49.528038115Z main DEBUG Returning file creation time for .../log/artemis.log
2026-11-02T11:50:49.529010771Z main DEBUG Setting prev file time to 2026-11-02T12:48:26.000+0100
2026-11-02T11:50:49.530286817Z main DEBUG LastRollForFile 2026-11-02T12:48:00.000+0100, LastRegularRole 2026-11-02T12:50:00.000+0100
(2026-11-02T12:48:26.000+0100), lastRollForFile=prevFire(fileTime)=2026-11-02T12:48:00.000+0100, lastRegularRoll=prevFire(now)=2026-11-02T12:50:00.000+0100, lastRollForFile.before(lastRegularRoll)=true

# Startup rollover archives the 12:48 file under the current minute (12:50)
2026-11-02T11:50:49.537060282Z main DEBUG RollingFileManager executing synchronous FileRenameAction[.../log/artemis.log to .../log/artemis.log.2026-11-02-12-50, renameEmptyFiles=false]
2026-11-02T11:50:49.537880477Z main DEBUG Now writing to .../log/artemis.log at 2026-11-02T12:50:49.537+0100
2026-11-02T11:50:49.539007046Z main DEBUG Log4j2 ConfigurationScheduler scheduled cron expression 0 * * * * ? to fire at 2026-11-02T12:51:00.000+0100

Reproduction

Use cron schedule 0 * * * * to test rolling every minute, to reproduce and speed up the tests.
evaluateOnStartup must be true.

config:

appender.log_file.filePattern = /var/log/logFile.log.%d{yyyy-MM-dd-HH-mm}
appender.log_file.policies.cron.schedule = 0 * * * * ?
appender.log_file.policies.cron.evaluateOnStartup = true
  • delete logFile.log, start the software at 12:48:26 (before 12:49:00) and keep producing log content. A new log is created, with lines from 12:48:26 onward
  • stop the software before 12:49:00, so the scheduled rollovers at 12:49:00 and 12:50:00 are missed
  • start the software again at 12:50:49. The file is rolled over on startup, but archived as logFile.log.2026-11-02-12-50 (the current minute) instead of logFile.log.2026-11-02-12-48 (the file's own minute). It contains the logs from 12:48:26 until the software was stopped
  • logFile.log is now empty, and lines from after 12:50:49 start appearing
  • at 12:51:00 the scheduled rollover also archives as logFile.log.2026-11-02-12-50, overwriting the file from startup. The data from 12:48:26 until the stop is lost
Lenguaje dominante
Java
Estrellas
3.6k
Forks
1.8k
Merge medio
5 d 6 h
PR fusionados (30 d)
24

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/logging-log4j2

Todos los issues de apache/logging-log4j2

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.