logrotate ne fait pas tourner les journaux

24

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?
Carmen
la source
Donc ça marche quand il est exécuté à la main? Est en crondmarche?
Kyle Smith
oui cela fonctionne, si vous voulez dire logrotate -f mysql_slow_query. Et crond court.
Carmen
Êtes-vous sûr qu'aucune autre configuration n'est déjà censée gérer ce fichier journal? Peut mysql-server- être ? Courez grep '/var/log/mysql' /etc/logrotate.d/*.
Zoredache
J'ai exécuté cette commande et seule ma config apparaît comme faisant quelque chose dans / var / log / mysql
Carmen
À quelle heure de la journée les tâches cron quotidiennes s'exécutent-elles dans votre configuration Ubuntu? Vous pouvez trouver ces informations dans le /etc/crontabfichier, dans la ligne qui se termine par /etc/cron.daily ). Peut-être que vous avez créé la configuration logrotate après que les tâches quotidiennes cron pour cette journée aient déjà été exécutées?
ricmarques

Réponses:

47

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.
user168717
la source
Fonctionne comme un champion!
Seth
6
En fait, il fait pivoter les journaux lors de l'utilisation -f(au moins sur mon dérivé RH).
bufh
12
-fpour la rotation forcée, -dpour le débogage, le débogage implique également une exécution à sec, donc aucune modification ne sera réellement effectuée pendant qu'il -dest activé.
ThorSummoner
1
-dimpliquant un essai à sec est délicat. Aucun changement n'était en cours et m'a fait me gratter la tête jusqu'à ce que je réalise ce fait.
Artem Russakovskii
5

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.

ricmarques
la source
0

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?

KCD
la source