логротат не обертаючи колоди

У мене є конфігурація 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. Де знаходиться журнал, який показує, що логротат був успішним? Я хочу подивитися, чи є щось, що могло б сказати, що виникла проблема.
2. Будь-які ідеї, чому логротат не працює?

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

Прописана дата стає опорною датою, з якої майбутні періоди logrotateвикористання використовуватимуться для порівняння "щоденних" обертань. Оскільки завдання за замовчуванням за замовчуванням виконується щодня, це, як правило, лише проблема щоденних завдань.

Ви можете уникнути цієї проблеми двома способами;

1. бігати sudo logrotate -f /etc/logrotate.d/<my rotate job>

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

2. Відредагуйте /var/lib/logrotate/statusта додайте рядок вручну:

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

   • встановивши його на сьогоднішню або попередню дату. Наступний запуск повинен спричинити його запуск.

Відповідно до наступної статті Slicehost:

Розуміння логротату в Ubuntu - частина 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... /var/lib/logrotate/statusфайл " зберігає інформацію про те, коли він востаннє обертав кожен файл журналу. " На сторінці з логротатом написано, що називається "файл стану".

Тут ще одна дискусія в ServerFault, яка також може бути корисною:

Як логротат точно обробляє "щоденно"?

У цій дискусії "MadHatter" говорить про наступне, що стосується файлу "статус" (штату):

"У кожному файлі є один рядок - це дата, коли він востаннє обертався; якщо ви запустили логротету в таку дату, що даний файл повинен повернутись до обертання, враховуючи кількість днів між поточною датою та датою у файлі ( 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 не записує помилку в новий файл після обертання?