Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Server] Default log config keeps only about 5 seconds of server log history

Abierto Apto para principiantes
#2,055 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@NopeCharon ya está trabajando en esto.

Desde el 26/10/2026.

  • #2056 de @NopeCharon — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java

Línea de trabajo

Empieza por etc/conf/server.log4j2.properties, especialmente por el patrón de archivos rotativos y la acción de retención descritos en el issue. Comprueba cómo interactúan las políticas existentes de tamaño y tiempo con strategy.max; el issue indica el patrón de archivado por hora previsto y la condición de antigüedad de siete días. Se considera terminado cuando la configuración predeterminada conserva los logs según su antigüedad y los rota cada hora, manteniendo la rotación basada en el tamaño.

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

Descripción

bug

Describe the bug

With the shipped etc/conf/server.log4j2.properties, the server rolls etc/logs/server.log into a new .gz archive every second that has log activity, and deletes all but the newest 5 archives. A server that logs steadily therefore keeps only about 5 seconds of history: startup lines are gone a few seconds after startup, and an ERROR line for a failed request is gone a few seconds after it is written.

The cause is the archive name pattern:

appender.rollingFile.filePattern = etc/logs/server-%d{MM-dd-yyyy-HH-mm-ss}-%i.log.gz
appender.rollingFile.policies.time.type = TimeBasedTriggeringPolicy
appender.rollingFile.policies.time.interval = 1
...
appender.rollingFile.strategy.action.ifAny.type = IfAccumulatedFileCount
appender.rollingFile.strategy.action.ifAny.exceeds = 5

TimeBasedTriggeringPolicy rolls over based on the most specific time unit in the date pattern, which here is seconds (ss), so interval = 1 means one archive per second. The Delete action then keeps at most 5 archives, regardless of how much time each one covers.

To Reproduce

  1. Start the server with the default config: bin/start-uc-server.
  2. Right after startup, list etc/logs: there are already two server-<date>-<time>-1.log.gz archives, and server.log holds only the last few startup lines.
  3. Send a request that logs a line once per second for about 10 seconds, for example:
    for i in $(seq 1 9); do
      curl -s -o /dev/null -X POST http://localhost:8080/api/2.1/unity-catalog/models \
        -H 'Content-Type: application/json' \
        -d "{\"name\":\"m$i\",\"catalog_name\":\"nope\",\"schema_name\":\"s\"}"
      sleep 1
    done
    
  4. List etc/logs again: the startup archives have been deleted, and the oldest surviving line is from the first request's second.

Observed after step 4:

server-10-25-2026-22-42-50-1.log.gz
server-10-25-2026-22-42-51-1.log.gz
server-10-25-2026-22-42-52-1.log.gz
server-10-25-2026-22-42-53-1.log.gz
server.log

Expected behavior

The default config keeps enough history to investigate a failure after the fact: days, not seconds. Archives roll every hour (and by size within an hour), and retention is counted by age rather than by number of archives.

Two changes:

  1. Roll hourly: drop the minutes and seconds from the date pattern, which keeps interval = 1 but makes it hourly. Putting the date in yyyy-MM-dd order also makes archives sort by name.
    appender.rollingFile.filePattern = etc/logs/server-%d{yyyy-MM-dd-HH}-%i.log.gz
    
  2. Keep archives by age: replace the two ifAny lines (IfAccumulatedFileCount, which would keep only 5 hours with hourly archives) with an IfLastModified condition, for example 7 days. The IfFileName condition stays.
    appender.rollingFile.strategy.action.age.type = IfLastModified
    appender.rollingFile.strategy.action.age.age = P7D
    

The 10MB SizeBasedTriggeringPolicy still splits a busy hour into -1, -2, ... archives. strategy.max = 5 caps those per hour, so an hour that logs more than 50MB overwrites its own oldest archive; raising max (for example to 20) avoids that. If disk use matters more than a fixed number of days, an IfAccumulatedFileSize cap can be added alongside the age condition.

System [please complete the following information]:

  • OS: Ubuntu (Linux 5.4), JDK 17
  • Unity Catalog: main at 8715cd5d, using the default etc/conf/server.log4j2.properties

Additional context

  • The Helm chart is not affected: it renders its own log4j2 config with a console appender and no rollover.
  • This also undercuts #1999, which makes each 5xx log one ERROR line with its cause and request ID: with the default config, that line can be deleted within seconds.
  • #1406 (for #1407) replaces this config file with a classpath default that rolls on size only. Whichever lands second should carry the hourly rolling and age-based retention over.
Lenguaje dominante
Java
Estrellas
3.6k
Forks
691
Merge medio
4 d 17 h
PR fusionados (30 d)
47

Preparar el entorno

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 unitycatalog/unitycatalog

Todos los issues de unitycatalog/unitycatalog

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.