logrotate Linux: Configurar Rotación de Logs

La gestión de logs es un pilar fundamental para cualquier administrador de sistemas Linux. Sin una estrategia eficaz, los archivos de log pueden crecer desmesuradamente, saturando el espacio en disco, comprometiendo el rendimiento del sistema y dificultando el análisis de eventos críticos o la resolución de problemas. En un entorno empresarial, donde cientos de servidores generan terabytes de datos cada día, un disco lleno debido a logs no gestionados puede detener servicios enteros, con costes operativos significativos.

logrotate es la herramienta estándar en Linux para automatizar la rotación, compresión y eliminación de archivos de log. Permite definir reglas precisas para cada aplicación, garantizando que los logs estén siempre disponibles para el análisis, pero sin ocupar espacio innecesariamente. Una configuración errónea de logrotate es una de las causas más comunes de discos llenos que he encontrado en entornos con 2.000 estaciones de trabajo y más de 300 VMs VMware, y una implementación correcta puede prevenir interrupciones de servicio y simplificar enormemente el trabajo de depuración y monitorización.

Probado en: Ubuntu 24.04 LTS · logrotate 3.21.0 · Octubre 2026

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás un sistema Linux (preferiblemente Ubuntu o Debian, pero los conceptos se aplican a cualquier distribución) con privilegios de sudo. logrotate está preinstalado en la mayoría de los sistemas Linux modernos. Utilizaremos una aplicación ficticia llamada app que escribe sus logs en /var/log/app/ y tiene un servicio systemd llamado app que debe recargarse después de la rotación de los logs.

Cómo funciona logrotate y cuándo se ejecuta

logrotate es una utilidad que se ejecuta en segundo plano, normalmente invocada por cron. En muchas distribuciones, existe un archivo /etc/cron.daily/logrotate que ejecuta el comando logrotate /etc/logrotate.conf una vez al día. El archivo /etc/logrotate.conf contiene las configuraciones globales e incluye todos los archivos presentes en el directorio /etc/logrotate.d/. Es en este último directorio donde crearemos los archivos de configuración específicos para nuestras aplicaciones.

Cuando logrotate se ejecuta, lee las configuraciones y verifica si es el momento de rotar los logs según las reglas definidas (por ejemplo, diariamente, semanalmente, por tamaño). Si es necesaria una rotación, procede con las acciones especificadas: renombra el archivo de log actual, crea uno nuevo (o lo vacía), lo comprime y elimina las copias más antiguas.

El archivo de configuración de una aplicación

Cada aplicación o servicio que genera logs puede tener su propio archivo de configuración dedicado en /etc/logrotate.d/. Este enfoque modular simplifica la gestión y el mantenimiento. Creemos un ejemplo para nuestra app ficticia:

# /etc/logrotate.d/app
/var/log/app/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 app app
    postrotate
        systemctl reload app
    endscript
}

Analicemos las directivas principales:

• /var/log/app/.log: Especifica los archivos de log a los que aplicar las reglas. El asterisco () indica todos los archivos con extensión .log dentro del directorio /var/log/app/.
• daily: La rotación se realizará cada día. Otras opciones comunes son weekly, monthly, yearly.
• rotate 14: Se mantendrán 14 copias de los logs rotados. Después de la decimocuarta rotación, la copia más antigua se eliminará.
• compress: Comprime los logs rotados (normalmente con gzip).
• delaycompress: Retrasa la compresión de un log rotado al siguiente ciclo. Útil si el servicio podría seguir escribiendo en el archivo recién rotado durante un breve período.
• missingok: No genera un error si el archivo de log no existe.
• notifempty: No rota el log si está vacío.
• create 0640 app app: Crea un nuevo archivo de log con permisos 0640 y propietario/grupo app:app después de la rotación. Esta es la opción preferida cuando el servicio es capaz de reabrir el nuevo archivo de log.

Frecuencia, número de copias y compresión

La elección de la frecuencia de rotación (daily, weekly, monthly, yearly) depende del volumen de logs generado y de la necesidad de análisis. Para servicios de alto tráfico, daily suele ser la mejor opción. El parámetro rotate N define durante cuántos ciclos se conservarán los logs rotados. Por ejemplo, rotate 7 con daily significa que se tendrán 7 días de logs históricos comprimidos.

La directiva compress es casi siempre aconsejable para ahorrar espacio en disco. delaycompress es particularmente útil en entornos donde los servicios podrían mantener un handle abierto en el archivo de log durante un breve período después de la rotación. De esta manera, el archivo se renombra en el primer ciclo y se comprime solo en el segundo, evitando problemas de acceso concurrente.

copytruncate o create: la diferencia clave

Este es uno de los puntos más críticos en la configuración de logrotate y a menudo fuente de errores. La elección entre copytruncate y create depende de cómo la aplicación gestiona sus archivos de log.

• create (predeterminado si no se especifica y no se usa copytruncate): logrotate mueve el archivo de log actual (por ejemplo, de app.log a app.log.1) y crea un nuevo archivo app.log vacío. Esta es la opción más eficiente. Sin embargo, requiere que la aplicación sea capaz de reabrir el nuevo archivo de log. Si la aplicación continúa escribiendo en el archivo renombrado, los nuevos eventos se perderán o se escribirán en un archivo ‘antiguo’ que ya no se monitorizará correctamente. Para solucionar esto, se utiliza la directiva postrotate.
• copytruncate: logrotate crea una copia del archivo de log actual y luego vacía el archivo original. El servicio continúa escribiendo en el archivo original, que ha sido vaciado. Este método es menos eficiente (requiere más I/O) pero es más seguro para aplicaciones que no pueden reiniciarse fácilmente o que no soportan la reapertura de logs. No requiere un postrotate para que el servicio reabra el log, pero puede causar la pérdida de algunos eventos de log entre la copia y el vaciado del archivo.

Lee también: Comando find Linux: 20 Ejemplos Prácticos

postrotate: hacer que el servicio reabra los logs

Como se mencionó, si se utiliza la directiva create (o si no se utiliza copytruncate), es fundamental informar al servicio de que su archivo de log ha sido movido y que debe empezar a escribir en un nuevo archivo. Esto se hace con la directiva postrotate.

    postrotate
        systemctl reload app
    endscript

El bloque postrotate/endscript contiene los comandos que se ejecutarán después de que se haya producido la rotación. En este caso, systemctl reload app envía una señal de recarga al servicio app. Muchos servicios (como nginx, apache, rsyslog) están diseñados para reabrir sus archivos de log cuando reciben una señal SIGHUP (que systemctl reload a menudo envía). Es fundamental verificar la documentación del servicio para entender qué comando es el más apropiado para hacer que reabra los logs sin interrumpir el servicio. Lee también: Systemd Avanzado: Creación de Servicios y Reincio Automático

Rotar por tamaño en lugar de por fecha

Además de la rotación basada en el tiempo, logrotate también soporta la rotación basada en el tamaño del archivo. Esto es particularmente útil para servicios que generan un volumen de logs muy variable o extremadamente elevado, donde una rotación diaria podría ser insuficiente o excesiva.

/var/log/another_app/*.log {
    size 100M
    rotate 5
    compress
    postrotate
        systemctl reload another_app
    endscript
}

La directiva size 100M indica que el log se rotará cuando alcance los 100 Megabytes. Puedes usar K para Kilobytes, M para Megabytes y G para Gigabytes. Si se especifican tanto size como una frecuencia temporal (daily, etc.), logrotate rotará el log cada vez que se cumpla una de las dos condiciones.

Probar la configuración sin modificar los archivos

Antes de implementar una nueva configuración en producción, es esencial probarla. logrotate ofrece modos de depuración que simulan la ejecución sin realizar cambios en los archivos reales.

Para una ejecución en modo depuración:

sudo logrotate -d /etc/logrotate.d/app

Este comando mostrará qué haría logrotate, incluyendo los motivos por los que un log se rotaría o no, y qué comandos postrotate se ejecutarían. Es una herramienta valiosa para la resolución de problemas.

Para forzar una rotación (útil para probar el postrotate o para liberar espacio en emergencia):

sudo logrotate -f /etc/logrotate.d/app

Esto ignorará las condiciones de frecuencia y tamaño y forzará la rotación de los logs especificados. Úsalo con precaución en producción, ya que podría activar el postrotate y recargar el servicio en un momento inoportuno.

Finalmente, para comprobar el estado de las rotaciones de logrotate (cuándo se rotó por última vez un determinado log):

cat /var/lib/logrotate/status

Este archivo contiene información sobre la última vez que cada log fue rotado, esencial para verificar que logrotate está funcionando como se esperaba.

Errores Comunes y Resolución de Problemas

1. Logs que no se rotan: Comprueba que el archivo de configuración esté en /etc/logrotate.d/ y que sea invocado por /etc/logrotate.conf. Verifica que el cronjob de logrotate esté activo (/etc/cron.daily/logrotate). Revisa los permisos de los archivos de log y de los directorios. Un error común es que logrotate no tenga los permisos para escribir en el directorio de logs o para renombrar los archivos. Lee también: Active Directory: Error ‘Relación de Confianza’ Resuelto
2. Servicio que no reabre el log: Si usas create y el servicio no reabre el log, los nuevos eventos se perderán. Asegúrate de que el comando en el bloque postrotate sea correcto y que el servicio esté configurado para responder a la señal apropiada (por ejemplo, SIGHUP). Pruébalo con sudo logrotate -f.
3. Archivos de log corruptos con copytruncate: Si un servicio escribe constantemente y de forma intensa, copytruncate puede llevar a logs corruptos o incompletos, ya que hay un pequeño intervalo entre la copia y el vaciado en el que el servicio podría escribir. En estos casos, create con un postrotate robusto es preferible.
4. Permisos incorrectos en los nuevos logs: Si el nuevo archivo de log se crea con permisos equivocados, el servicio podría no ser capaz de escribir en él. Usa la directiva create MODE OWNER GROUP para especificar los permisos correctos.

FAQ — Preguntas Frecuentes

¿Debo reiniciar el servicio después de modificar logrotate?

No, no es necesario reiniciar el propio servicio logrotate. Las modificaciones a los archivos de configuración en /etc/logrotate.d/ se leen cada vez que logrotate se ejecuta desde el cronjob diario. Sin embargo, si has modificado el bloque postrotate para una aplicación específica, podrías querer forzar una rotación con sudo logrotate -f /etc/logrotate.d/app para asegurarte de que el comando postrotate se ejecute y pruebe inmediatamente.

¿Cuál es la diferencia entre compress y delaycompress?

compress comprime inmediatamente el archivo de log recién rotado. delaycompress retrasa la compresión un ciclo de rotación. Esto significa que el archivo app.log.1 (el log recién rotado) permanecerá sin comprimir hasta la próxima ejecución de logrotate, cuando se comprimirá en app.log.1.gz. Es útil para servicios que podrían seguir leyendo del archivo recién rotado durante un breve período, evitando errores de acceso a archivos comprimidos.

¿Puedo usar logrotate para rotar los logs de Docker?

Sí, es posible. Los logs de Docker suelen gestionarse a través del driver de logging configurado para los contenedores. Sin embargo, si tus contenedores escriben logs en archivos en el filesystem del host, puedes configurar logrotate para esos archivos. Un enfoque común es configurar el driver de logging de Docker (por ejemplo, json-file con max-size y max-file) y luego usar logrotate para gestionar los logs del propio demonio Docker, que se encuentran típicamente en /var/lib/docker/containers/ o similares.

¿Cómo puedo excluir un cierto tipo de log de la rotación?

logrotate permite especificar patrones de inclusión y exclusión. Si tienes un patrón genérico como *.log pero quieres excluir debug.log, puedes usar la directiva tabooext en el archivo de configuración principal /etc/logrotate.conf o un archivo de configuración específico con un patrón más preciso para la inclusión. En general, es mejor ser específico con los patrones de inclusión para evitar rotaciones no deseadas.

Conclusiones con Puntos Clave Operativos

La correcta configuración de logrotate es una operación que, una vez establecida, te ahorrará innumerables quebraderos de cabeza relacionados con discos llenos y pérdida de datos. Recuerda siempre:

1. Crear archivos de configuración dedicados para cada aplicación en /etc/logrotate.d/.
2. Elegir cuidadosamente entre copytruncate y create, según el comportamiento de tu servicio.
3. Implementar siempre un bloque postrotate para que los servicios reabran los logs cuando uses create.
4. Probar cada nueva configuración con sudo logrotate -d antes de aplicarla en producción.
5. Monitorizar el archivo /var/lib/logrotate/status para asegurarte de que las rotaciones se realicen regularmente.

Una gestión proactiva de los logs no es solo una buena práctica, sino un requisito indispensable para la estabilidad y la seguridad de cualquier infraestructura Linux.

Fuentes

• logrotate man page
• Systemd documentation

Actualizado: Octubre 2026