logrotate не вращая журналы

У меня есть эта конфигурация logrotate, и я работаю на 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

}

Я поместил это в /etc/logrotate.d вчера, и сегодня журнал не вращался.

Ниже приведены вещи, которые я сделал:

1. Я проверил, что журнал действительно находится в /var/log/mysql/mysql-slow.log
2. строки mysqladmin работают нормально при запуске от имени пользователя root
3. mysql может записывать в mysql-slow.log

Когда я сделал это:

$ 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. Где находится журнал, который показывает, что logrotate был успешным? Я хочу посмотреть, есть ли что-то, что скажет, что была проблема.
2. Любые идеи о том, почему не работает logrotate?

Распространенной проблемой является то, что при первой настройке ежедневной записи logrotate.d она не будет вращаться в первый день. Когда вы используете ротацию, основанную на времени (ежедневно / еженедельно / ежемесячно), logrotate набрасывает отметку даты последней даты, в которой он увидел файл /var/lib/logrotate/status(или /var/lib/logrotate.statusв системах RHEL).

Пометленная дата становится контрольной датой, которую будущие прогоны logrotateбудут использовать для сравнения «ежедневных» оборотов. Поскольку задание по умолчанию cron выполняется ежедневно, это обычно является проблемой только в повседневных заданиях.

Вы можете избежать этой проблемы двумя способами;

1. бег sudo logrotate -f /etc/logrotate.d/<my rotate job>

   • Это будет записывать дату в файл состояния и вращать журналы
     
     

2. Отредактируйте /var/lib/logrotate/statusи добавьте строку вручную:

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

   • установив его на сегодняшний или предыдущий день. Следующий запуск должен привести к его запуску.

Согласно следующей статье Slicehost:

Понимание logrotate в Ubuntu - часть 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... /var/lib/logrotate/statusфайл " хранит информацию о том, когда он последний раз поворачивал каждый файл журнала. " В manrotate logrotate написано, что это называется "файлом состояния".

В ServerFault есть еще одно обсуждение, которое также может быть полезным:

Как logrotate точно обрабатывает «ежедневно»?

В этом обсуждении «MadHatter» говорит относительно следующего относительно файла «status» (state):

«Каждый файл имеет одну строку, которая является датой, когда он последний раз вращался; если вы запускаете logrotate в такую ​​дату, когда данный файл подлежит ротации, учитывая количество дней между текущей датой и датой в файле ( 1 для ежедневного, 7 для еженедельного и т. Д.), Файл будет повернут ".

Надеюсь, это поможет.

Если mysqladminтребуется пользователь или пароль, он не будет считывать его из /root/.my.cnfконфигурации без изменений.

Попробуйте передать результаты в журнал, чтобы увидеть, что происходит.

  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 не записывает ошибку в новый файл после вращения?