Twoja konfiguracja logrotate wygląda poprawnie na pierwszy rzut oka, ale puste nowe pliki logów po rotacji to typowy objaw problemu z sygnałem do Apacha o ponownym otwarciu plików logów po rotacji. Oto najczęstsze przyczyny i rozwiązania:

1. Brakujący postrotate z sygnałem do Apacha

Apache trzyma otwarte uchwyty do plików logów. Po rotacji (przeniesieniu/skompresowaniu starego pliku) Apache nadal pisze do starego uchwytu, a nowy plik pozostaje pusty, ponieważ Apache nie wie, że ma zacząć pisać do nowego.

Rozwiązanie: Dodaj blok postrotate z komendą systemctl reload apache2 (lub service apache2 reload na starszych systemach):

/var/log/apache2/*.log {
    rotate 14
    daily
    compress
    delaycompress
    postrotate
        /usr/sbin/apache2ctl graceful > /dev/null 2>&1 || true
    endscript
}

• graceful – Powoduje, że Apache ponownie otwiera pliki logów bez przerywania obsługi żądań.
• > /dev/null 2>&1 – Tłumi komunikaty (opcjonalnie, dla czystości logów systemowych).
• || true – Zapewnia, że logrotate nie zwróci błędu, jeśli komenda się nie powiedzie.

Uwaga: Jeśli używasz systemd, możesz też użyć:

conf

Copy

    postrotate
        systemctl reload apache2 > /dev/null 2>&1 || true
    endscript

2. Sprawdź, czy logrotate naprawdę działa

• Testuj konfigurację przed zastosowaniem:
  bash

  Copy

  sudo logrotate -d /etc/logrotate.d/apache2

  (Pokaże, co zrobi logrotate bez wprowadzania zmian.)
• Wymuś rotację ręcznie:
  bash

  Copy

  sudo logrotate -vf /etc/logrotate.d/apache2

  Sprawdź, czy pliki zostały zrotowane i czy Apache pisze do nowych.

3. Uprawnienia do plików logów

• Upewnij się, że Apache ma uprawnienia do pisania do nowych plików. Sprawdź:
  bash

  Copy

  ls -la /var/log/apache2/

  Pliki powinny należeć do użytkownika, pod którym działa Apache (zwykle www-data):
  bash

  Copy

  sudo chown www-data:www-data /var/log/apache2/*.log
  sudo chmod 640 /var/log/apache2/*.log

4. delaycompress a puste pliki

• delaycompress opóźnia kompresję o jedną rotację (np. access.log.1 nie jest kompresowany, dopóki nie powstanie access.log.2). To nie powoduje pustych plików, ale sprawdź, czy nie masz innych reguł, które mogłyby zakłócać proces.

5. Sprawdź logi systemowe

• Szukaj błędów w:
  bash

  Copy

  sudo tail -n 50 /var/log/syslog
  sudo journalctl -u apache2 --no-pager -n 50

  Czasami logrotate lub Apache zgłaszają tam błędy (np. brak uprawnień, nieznaleziony plik).

Podsumowanie kroków naprawczych

1. Dodaj postrotate z apache2ctl graceful lub systemctl reload apache2.
2. Przetestuj logrotate -d i logrotate -vf.
3. Sprawdź uprawnienia plików logów.
4. Zweryfikuj logi systemowe pod kątem błędów.

Czy po dodaniu postrotate problem zniknął? Jeśli nie, sprawdź, czy Apache nie używa innej ścieżki do logów (np. przez ErrorLog w konfiguracji wirtualnych hostów).