logrotate ne fait pas tourner les journaux

J'ai cette configuration logrotate et je fonctionne sur 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

}

J'ai mis cela dans /etc/logrotate.d hier et aujourd'hui, le journal n'a pas été tourné.

Voici les choses que j'ai faites:

1. J'ai vérifié que le journal se trouve bien dans /var/log/mysql/mysql-slow.log
2. Les lignes mysqladmin fonctionnent correctement lorsqu'elles sont exécutées en tant que root
3. mysql est capable d'écrire dans le mysql-slow.log

Quand j'ai fait ça:

$ 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. Où se trouve le journal qui indique que le logrotate a réussi? Je veux voir s'il y a quelque chose qui dirait qu'il y a eu un problème.
2. Des idées sur pourquoi le logrotate ne fonctionne pas?

Un problème courant est que lorsque vous configurez une entrée logrotate.d quotidiennement, elle ne tourne pas le premier jour. Lorsque vous utilisez une rotation basée sur l'heure (quotidienne / hebdomadaire / mensuelle), logrotate griffonne un horodatage de la dernière date à laquelle il a vu le fichier dans /var/lib/logrotate/status(ou /var/lib/logrotate.statussur les systèmes RHEL).

La date gribouillée devient la date de référence à partir de laquelle les futures exécutions logrotateseront utilisées pour comparer les rotations «quotidiennes». Étant donné que le travail cron par défaut s'exécute quotidiennement, il s'agit généralement uniquement d'un problème dans les travaux quotidiens.

Vous pouvez éviter ce problème de deux manières;

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

   • Cela gribouillera la date dans le fichier d'état et fera tourner les journaux
     
     

2. Modifiez /var/lib/logrotate/statuset ajoutez la ligne manuellement:

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

   • en le fixant à la date d'aujourd'hui ou à une date antérieure. La prochaine exécution devrait provoquer son exécution.

Selon l'article suivant de Slicehost:

Comprendre logrotate sur Ubuntu - partie 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... le /var/lib/logrotate/statusfichier " stocke des informations sur la dernière rotation de chaque fichier journal. ". La page de manuel logrotate dit que cela s'appelle un "fichier d'état".

Il y a une autre discussion ici dans ServerFault qui peut également être utile:

Comment logrotate gère-t-il exactement "quotidiennement"?

Dans cette discussion, "MadHatter" dit, concernant ce qui suit, concernant le fichier "état" (état):

"Chaque fichier comporte une ligne, qui correspond à la date de la dernière rotation. Si vous exécutez logrotate à une date telle qu'un fichier donné doit être tourné, compte tenu du nombre de jours entre la date actuelle et la date dans le fichier ( 1 pour quotidien, 7 pour hebdomadaire, etc.), le fichier sera tourné. "

J'espère que ça aide.

Si mysqladminnécessite un utilisateur ou un mot de passe, il ne le lira pas de la /root/.my.cnfconfiguration sans modification.

Essayez de canaliser votre sortie vers l'enregistreur pour voir ce qui se passe.

  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 ne consigne pas d'erreur dans le nouveau fichier après la rotation?