logrotate nie obraca dzienników

Mam tę konfigurację Logrotate i działam na 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

}

Wczoraj umieściłem to w /etc/logrotate.d, a dzisiaj dziennik nie został obrócony.

Poniżej są rzeczy, które zrobiłem:

1. Sprawdziłem, czy dziennik rzeczywiście znajduje się w /var/log/mysql/mysql-slow.log
2. Linie mysqladmin działają dobrze, gdy są uruchamiane jako root
3. mysql może zapisywać do mysql-slow.log

Kiedy to zrobiłem:

$ 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. Gdzie jest dziennik pokazujący, że logrotate się powiódł? Chcę sprawdzić, czy jest coś, co powiedziałoby, że wystąpił problem.
2. Wszelkie pomysły na to, dlaczego logrotate nie działa?

Częstym problemem jest to, że kiedy pierwszy raz konfigurujesz codzienny wpis logrotate.d, nie będzie on obracany pierwszego dnia. Gdy używasz rotacji opartej na czasie (dzienna / tygodniowa / miesięczna), logrotate zapisuje znacznik daty ostatniej daty, w której plik był widziany /var/lib/logrotate/status(lub /var/lib/logrotate.statusw systemach RHEL).

Zapisana data staje się datą odniesienia od przyszłych serii, które logrotatebędą używane do porównywania „dziennych” obrotów. Ponieważ domyślne zadanie cron jest uruchamiane codziennie, jest to zwykle problem tylko w codziennych zadaniach.

Możesz uniknąć tego problemu na dwa sposoby;

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

   • Spowoduje to zapisanie daty w pliku statusu i obrócenie dzienników
     
     

2. Edytuj /var/lib/logrotate/statusi dodaj wiersz ręcznie:

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

   • ustawiając go na dzisiejszą lub wcześniejszą datę. Następne uruchomienie powinno spowodować jego uruchomienie.

Zgodnie z następującym artykułem Slicehost:

Zrozumienie logrotate na Ubuntu - część 2
http://articles.slicehost.com/2010/6/30/understanding-logrotate-on-ubuntu-part-2

... /var/lib/logrotate/statusplik „ przechowuje informacje o tym, kiedy ostatnio obrócił każdy plik dziennika. ”. Strona logrotate mówi, że nazywa się to „plikiem stanu”.

W ServerFault jest kolejna dyskusja, która może być również przydatna:

Jak dokładnie logrotate radzi sobie z „codziennym”?

W tej dyskusji „MadHatter” mówi w odniesieniu do pliku „status” (stan):

„Każdy plik ma jeden wiersz, który jest datą jego ostatniej rotacji; jeśli uruchomisz logrotate w taką datę, że dany plik ma zostać zmieniony, biorąc pod uwagę liczbę dni między bieżącą datą a datą w pliku ( 1 na dzień, 7 na tydzień itd.), Plik zostanie obrócony. ”

Mam nadzieję, że to pomoże.

Jeśli mysqladminwymaga użytkownika lub hasła, nie odczyta go z /root/.my.cnfkonfiguracji bez modyfikacji.

Spróbuj przesłać dane wyjściowe do rejestratora, aby zobaczyć, co się dzieje.

  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 nie rejestruje błędu do nowego pliku po obróceniu?