logrotate no gira los registros

Tengo esta configuración de logrotate y estoy ejecutando Ubuntu 10.04.

/var/log/mysql/mysql-slow.log {
    daily
    rotate 3
    compress
    notifempty
    missingok
    create 660 mysql adm
    postrotate 
    if test -x /usr/bin/mysqladmin && \
       /usr/bin/mysqladmin  ping &>/dev/null
    then
       /usr/bin/mysqladmin  flush-logs
    fi
endscript

}

Puse esto en /etc/logrotate.d ayer y hoy el registro no fue rotado.

A continuación están las cosas que he hecho:

1. Verifiqué que el registro está en /var/log/mysql/mysql-slow.log
2. Las líneas mysqladmin funcionan bien cuando se ejecutan como root
3. mysql puede escribir en mysql-slow.log

Cuando hice esto:

$ logrotate -d -f mysql-slow

reading config file mysql-slow
reading config info for /var/log/mysql/mysql-slow.log 

Handling 1 logs

rotating pattern: /var/log/mysql/mysql-slow.log  forced from command line (3 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/mysql/mysql-slow.log

log needs rotating
rotating log /var/log/mysql/mysql-slow.log, log->rotateCount is 3
dateext suffix '-20120329'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/mysql/mysql-slow.log.3.gz to /var/log/mysql/mysql-slow.log.4.gz     (rotatecount 3, logstart 1, i 3), 
renaming /var/log/mysql/mysql-slow.log.2.gz to /var/log/mysql/mysql-slow.log.3.gz (rotatecount 3, logstart 1, i 2), 
renaming /var/log/mysql/mysql-slow.log.1.gz to /var/log/mysql/mysql-slow.log.2.gz (rotatecount 3, logstart 1, i 1), 
renaming /var/log/mysql/mysql-slow.log.0.gz to /var/log/mysql/mysql-slow.log.1.gz (rotatecount 3, logstart 1, i 0), 
renaming /var/log/mysql/mysql-slow.log to /var/log/mysql/mysql-slow.log.1
creating new /var/log/mysql/mysql-slow.log mode = 0660 uid = 20004 gid = 4
running postrotate script
running script (multiple) with arg /var/log/mysql/mysql-slow.log : " 
    if test -x /usr/bin/mysqladmin && \
       /usr/bin/mysqladmin &>/dev/null
    then
       /usr/bin/mysqladmin flush-logs
    fi
"
compressing log with: /bin/gzip
removing old log /var/log/mysql/mysql-slow.log.4.gz

1. ¿Dónde está el registro que muestra que logrotate fue exitoso? Quiero ver si hay algo que diga que hubo un problema.
2. ¿Alguna idea de por qué el logrotate no funciona?

Un problema común es cuando configura por primera vez una entrada diaria logrotate.d, no rotará el primer día. Cuando utiliza una rotación basada en el tiempo (diaria / semanal / mensual) logrotate garabatea una marca de fecha de la última fecha en que vio el archivo /var/lib/logrotate/status(o /var/lib/logrotate.statusen los sistemas RHEL).

La fecha garabateada se convierte en la fecha de referencia a partir de la que logrotatese utilizarán futuras ejecuciones para comparar rotaciones 'diarias'. Dado que el trabajo cron predeterminado se ejecuta diariamente, esto generalmente es solo un problema en los trabajos diarios.

Puede evitar este problema de dos maneras;

1. correr sudo logrotate -f /etc/logrotate.d/<my rotate job>

   • Esto garabateará la fecha en el archivo de estado y rotará los registros
     
     

2. Edite /var/lib/logrotate/statusy agregue la línea manualmente:

   "/var/log/my_special.log" 2013-4-8

   • configurándolo a la fecha actual o anterior. La próxima ejecución debería hacer que se ejecute.

De acuerdo con el siguiente artículo de Slicehost:

Comprender logrotate en Ubuntu - parte 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... el /var/lib/logrotate/statusarchivo " almacena información sobre cuándo giró por última vez cada archivo de registro ". La página de manual logrotate dice que se llama un "archivo de estado".

Hay otra discusión aquí en ServerFault que también puede ser útil:

¿Cómo maneja logrotate exactamente "diariamente"?

En esa discusión, "MadHatter" dice, con respecto a lo siguiente, con respecto al archivo de "estado" (estado):

"Cada archivo tiene una línea, que es la fecha en la que se giró por última vez; si ejecuta logrotate en una fecha tal que un archivo determinado debe rotar, dada la cantidad de días entre la fecha actual y la fecha en el archivo ( 1 para diario, 7 para semanal, etc.), el archivo se rotará ".

Espero que esto ayude.

Si mysqladminrequiere un usuario o contraseña, no lo leerá desde la /root/.my.cnfconfiguración sin modificación.

Intente canalizar su salida al registrador para ver qué está sucediendo.

  postrotate
      # just if mysqld is really running
      if test -x /usr/bin/mysqladmin && \
         /usr/bin/mysqladmin ping &>/dev/null
      then
         env HOME=/root/ /usr/bin/mysqladmin flush-logs 2>&1 | logger
      else
         logger "mysqladmin ping failed so not rotating mysql logs"
      fi
  endscript

¿MySQL no registra el error en el nuevo archivo después de rotar?