Назад | Перейти на главную страницу

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 файл "хранит информацию о том, когда он последний раз менял каждый файл журнала.". страница руководства logrotate говорит, что это называется "файл состояния".

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

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

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

"В каждом файле есть одна строка, которая представляет собой дату последней ротации; если вы запустите 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 не записывает ошибку в новый файл после поворота?

Попробуйте проверить вывод logrotate на наличие слова «ошибка». Похоже, что logrotate пропускает некоторые задачи (но не все задачи) при обнаружении ошибок.

Например, в Debian / Ubuntu вы можете запустить:

/usr/sbin/logrotate /etc/logrotate.conf --verbose --force |& grep -i '[^-_/.]error'

Регулярное выражение предназначено для избежания перечисления файлов, содержащих слово «ошибка». Амперсанд также перенаправляет stderr на grep.