Próbuję zmusić Logrotate do pracy na moim VPS, aby co tydzień obracać plikami apache. Obecnie zawartość pliku konfiguracyjnego apache2 jest taka.
"/var/www/user/site.com/logs/*.log" {
weekly
missingok
rotate 8
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null
endscript
}
Zostawiłem to już od dwóch tygodni i o ile wiem, nic się nie zmieniło. Kiedy symuluję to z wiersza poleceń, otrzymuję następujący wynik.
user@geneva:/var/lib/logrotate$ /usr/sbin/logrotate -d /etc/logrotate.d/apache2
reading config file /etc/logrotate.d/apache2
reading config info for "/var/www/user/site.com/logs/*.log"
Handling 1 logs
rotating pattern: "/var/www/user/site.com/logs/*.log" weekly (8 rotations)
empty log files are not rotated, old logs are removed
considering log /var/www/user/site.com/logs/access.log
log does not need rotating
considering log /var/www/user/site.com/logs/error.log
log does not need rotating
not running postrotate script, since no logs were rotated
Wszelkie pomysły na to, co źle skonfigurował Iv'e?
Mój plik statusu też jest pusty :(
user@geneva:~$ cat /var/lib/logrotate/status
logrotate state -- version 2
Aktualizacja
Usunąłem plik statusu i przeprowadziłem wymuszone uruchomienie programu logrotate, a teraz dzienniki wyglądają, jakby zostały obrócone, a plik statusu wygląda bardziej obiecująco!
sudo rm /var/lib/logrotate/status
sudo /usr/sbin/logrotate -f /etc/logrotate.conf
/var/lib/logrotate.status
z datą co najmniej tygodniową. Zaktualizowałem odpowiedź za pomocą przykładu ...Może to być spowodowane tym, że pliki dziennika są puste.
Taka sytuacja może się zdarzyć, ponieważ apache nadal zapisuje w poprzednim pliku dziennika, którego nazwa została zmieniona bez ponownego uruchamiania apache. Access.log stał się access.log.1 i Apache zapisuje w nim.
Lub masz problem z czasem tworzenia dziennika:
źródło
notifempty
linię, aby poradzić sobie z dziennikami 0-bajtowymi, które się nie obracają. Następnie będziesz chciałtouch
nowego pliku dziennika przed każdym testem, aby logrotate miał coś do obrócenia.Napotkałem podobny problem, ale żadna z tych odpowiedzi mi nie pomogła. Mój plik dziennika był ogromny i stary, moja konfiguracja była w 100% poprawna i poprawna, usunięcie pliku statusu nie pomogło.
Okazało się, że problemem były zduplikowane wpisy logrotate . Kiedy uruchamiam logrotate ręcznie na moim pliku konfiguracyjnym tylko w ten sposób:
nie pokazał żadnych błędów, po prostu powiedział:
Nadal nie wiem dlaczego. Ale kiedy uruchomię takie pełne polecenie logrotate:
Mam następujący wiersz:
Okazało się, że plik konfiguracyjny logrotate dla mojej usługi zawierał wpisy dotyczące obracania dzienników dostępu nginx, a także samych dzienników usługi. I to kolidowało z konfiguracją ngnix logrotate, która ma regułę dla wszystkich wpisów nginx:
Więc rozwiązanie dla mojej sprawy jest dość proste: po prostu musiałem usunąć sprzeczną regułę rotacji logów nginx z mojej konfiguracji .
Przypuszczam, że logrotate zaczął przerywać przetwarzanie pliku w przypadku konfliktu reguł tylko z jednej z najnowszych wersji. Pojawia się ten błąd w wersji 3.7.7, ale w wersji 3.7.7 z tą samą sprzeczną konfiguracją zapisuje ten sam błąd, ale obraca się dobrze. Chociaż nie mogłem znaleźć żadnego zapisu w dzienniku zmian Logrotate.
źródło
Spróbuj uruchomić
sudo logrotate -f --verbose /etc/logrotate.d/apache2
Zobacz, co napisano w konsoli i napraw wszystko, co jest nie tak.źródło
Miałem maszynę Debian 7, która po aktualizacji systemu nie obracała już dzienników poczty. Wszystkie inne dzienniki oprócz dzienników zostały poprawnie obrócone. Odkryłem, że dzienniki poczty wzrosły o kilka gigabajtów. Zawsze zarządzałem rotacją logów przez Webmin. Następnie działając
logrotate -d /etc/logrotate.conf
zobaczyłem następujący komunikat:Ignoring rsyslog.dpkg-old, because of .dpkg-old ending
Okazało się, że moje wpisy rotacji poczty zostały wymienione
/etc/logrotate.d/rsyslog.dpkg-old
, co zostało zignorowane! Zmiana nazwy pliku naprawiła rotację pliku dziennika :-)źródło