Ошибка logrotate failed: причины и способы исправления

Что означает ошибка logrotate failed

Ошибка logrotate failed — это общее уведомление от системы планирования задач (обычно cron или systemd timer), что служба ротации логов logrotate завершилась с ошибкой. Это не конкретный код ошибки, а статус завершения процесса. Сама причина ошибки никогда не указана в этом сообщении. Её нужно искать в логах самого logrotate.

Типичный вывод в системном журнале (/var/log/syslog или через journalctl) может выглядеть так:

error: error rotating /var/log/nginx/access.log: cannot open '/var/log/nginx/access.log' for reading: Permission denied

Или:

error: error creating new /var/log/nginx/access.log.1.gz (is filesystem full?): No space left on device

Конфигурация logrotate обычно запускается ежедневно через системный таймер logrotate.timer (systemd) или задачу в /etc/cron.daily/. Ошибка означает, что ротация логов не произошла, и старые логи продолжают расти, что может привести к переполнению диска.

Причины возникновения

Ошибка logrotate failed — это симптом. Вот наиболее частые первопричины:

Недостаточно прав доступа (Permission denied). У пользователя, от которого работает logrotate (обычно root), нет прав на чтение исходного лог-файла, запись в каталог с архивами или создание нового (сжатого) файла. Часто возникает, если логи создаются другим пользователем (например, www-data для веб-сервера) и имеют слишком строгие права.
Недостаточно места на диске (No space left on device). На разделе, где хранятся исходные логи или куда должны сохраняться сжатые архивы (.gz), закончилось свободное место. logrotate не может создать новый файл или сжать старый.
Некорректный путь к файлу в конфигурации. В файлах конфигурации в /etc/logrotate.d/ указан несуществующий путь к лог-файлу или каталогу.
Конфликтующие или синтаксически некорректные конфиги. Ошибка в одном из файлов в /etc/logrotate.d/ (например, пропущена закрывающая фигурная скобка }) может привести к падению всего процесса.
Файл лога заблокирован другим процессом. Веб-сервер (nginx, Apache) или другое приложение держит файл в эксклюзивной блокировке, и logrotate не может его переименовать (что является первым шагом ротации).
Проблема с утилитой сжатия (gzip). Если в конфиге включено сжатие (compress или delaycompress), но утилита gzip отсутствует или повреждена, ротация завершится ошибкой.
Ошибка в скрипте postrotate/prerotate. Если в конфигурации указаны пользовательские скрипты, их выполнение может завершиться с ошибкой, что приведёт к падению всей задачи.

Способы решения

Способ 1: Анализ точного сообщения об ошибке (Обязательный первый шаг)

Прежде чем что-то исправлять, необходимо найти истинную причину ошибки.

Проверьте журнал systemd (если используется systemd-timer):
```
sudo journalctl -u logrotate.service --since "1 hour ago" | grep -i error
```
Или просто просмотрите весь лог службы:
```
sudo journalctl -u logrotate.service -n 50
```

Проверьте системный лог (если используется cron.daily):

sudo grep -i "logrotate" /var/log/syslog | tail -n 50

Или, на CentOS/RHEL:

sudo grep -i "logrotate" /var/log/messages | tail -n 50

Найдите строки, содержащие error:. Именно они содержат описание проблемы (например, Permission denied, No space left on device, error: ...).

Способ 2: Проверка и корректировка прав доступа

Если в логах видите Permission denied:

Определите, от какого пользователя/группы запускается процесс. Обычно это root.
Проверьте владельца и права на проблемный лог-файл и его родительский каталог:
```
ls -la /var/log/nginx/access.log
ls -ld /var/log/nginx/
```
Вариант А (рекомендуется): Измените группу лог-файла на группу, от которой работает приложение (например, www-data), и дайте группе права на запись. Затем убедитесь, что logrotate (запускаемый от root) может читать файл.
```
sudo chown root:www-data /var/log/nginx/access.log
sudo chmod 640 /var/log/nginx/access.log
```
Убедитесь, что каталог /var/log/nginx/ доступен для root на выполнение (+x).
Вариант Б (менее безопасно): Временно дайте полные права для диагностики (не оставляйте так!):
```
sudo chmod 666 /var/log/nginx/access.log
```
После исправления проблемы верните безопасные права.

Способ 3: Освобождение дискового пространства

Если причина — No space left on device:

Проверьте использование диска:
```
df -h
```
Найдите раздел, который заполнен (например, /var или /).
Очистите старые или ненужные логи вручную (осторожно!):
```
# Просмотр самых больших файлов в /var/log
sudo du -sh /var/log/* | sort -rh | head -n 10
# Очистка старых сжатых логов (пример для nginx)
sudo rm -f /var/log/nginx/*.gz
```
Внимание: Не удаляйте активные (текущие) лог-файлы без точки (например, access.log). Удаляйте только архивы (*.gz, *.1 и т.д.).
После очистки запустите logrotate вручную, чтобы проверить, заработал ли он:
```
sudo logrotate -f /etc/logrotate.conf
```

Способ 4: Проверка и тестирование конфигурации

Проверьте синтаксис всех конфигов:
```
sudo logrotate -d /etc/logrotate.conf
```
Ключ -d включает режим отладки. Логика ротации будет пройдена, но никакие файлы не будут фактически переименованы, удалены или сжаты. Это безопасно.
Внимательно изучите вывод. Ищите строки reading config file (убедитесь, что читаются все нужные файлы из /etc/logrotate.d/) и error:. Распространённая ошибка — отсутствие закрывающей } в одном из файлов.
Если нашли проблемный конфиг в /etc/logrotate.d/, отредактируйте его. Например, для сервиса app:
```
sudo nano /etc/logrotate.d/app
```
Убедитесь, что пути к логам существуют:
```
sudo ls -la /var/log/app/
```

Способ 5: Решение проблемы с блокировкой файлов

Если приложение (например, nginx) держит файл открытым, logrotate может не смочь его переименовать. Используйте директиву copytruncate в конфигурации для этого конкретного лога.

Отредактируйте конфиг для проблемного сервиса (например, /etc/logrotate.d/nginx).

Для блока, отвечающего за access.log и error.log, вместо стандартного:

/var/log/nginx/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

Добавьте строку copytruncate сразу после {:

/var/log/nginx/*.log {
    copytruncate  # <-- Добавлено
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    ...
}

copytruncate копирует текущий лог в новый файл и обнуляет исходный, что позволяет приложению продолжать писать в тот же дескриптор. Это менее атомарно, чем стандартный метод (переименование), но решает проблему блокировок.

Способ 6: Принудительный запуск и финальная проверка

После внесения изменений:

Принудительно запустите ротацию (флаг -f):
```
sudo logrotate -f /etc/logrotate.conf
```
Если команда завершилась без вывода ошибок — отлично.
Проверьте, что архивы создались:
```
ls -la /var/log/nginx/ | grep ".gz"
```
Должны появиться файлы вида access.log.1.gz.
Проверьте, что новый лог-файл создан и пуст (или имеет размер 0):
```
sudo ls -la /var/log/nginx/access.log
```
Дождитесь следующего планового запуска (или проверьте через день) и снова просмотрите системные логи на наличие ошибок.

Профилактика

Регулярный мониторинг дискового пространства. Добавьте проверку /var в ваши системы мониторинга (Zabbix, Prometheus, Nagios). Критический порог — 80-90%.
Стандартизация прав доступа. Настройте ваши приложения (веб-серверы, базы данных) так, чтобы они создавали логи с групповым доступом, который может читать root. Например, для nginx: chown root:adm и chmod 640 для логов.
Ежегодный аудит конфигураций logrotate. Проверяйте файлы в /etc/logrotate.d/ на наличие устаревших путей или конфигов для удалённых программ.
Используйте copytruncate осознанно. Применяйте эту опцию только для приложений, которые не поддерживают сигналы на ротацию логов (например, некоторые Java-приложения). Для nginx, Apache, haproxy лучше использовать стандартный метод с postrotate/prerotate.
Тестирование изменений. Любое изменение в конфигах logrotate или в правах на логи проверяйте командой sudo logrotate -d /etc/logrotate.conf до того, как система запустит их автоматически.

Способ 7: Отладка через подробный журнал (для сложных случаев)

Если стандартные методы не помогли, включите максимально подробное логирование logrotate.

Создайте файл для подробного лога:

sudo touch /var/log/logrotate-debug.log
sudo chmod 644 /var/log/logrotate-debug.log

Запустите logrotate с перенаправлением всего вывода (stdout и stderr) в этот файл:
```
sudo logrotate -d /etc/logrotate.conf 2>&1 | sudo tee /var/log/logrotate-debug.log
```
Или для реального запуска (флаг -v для подробности):
```
sudo logrotate -vf /etc/logrotate.conf 2>&1 | sudo tee -a /var/log/logrotate-debug.log
```
Изучите полученный файл /var/log/logrotate-debug.log. Он покажет последовательность чтения конфигов, проверки каждого файла и точное место, где происходит сбой. Это самый надёжный способ диагностики.

Важно: После диагностики не забудьте удалить или очистить отладочный лог, чтобы он сам не стал причиной переполнения диска.

Часто задаваемые вопросы

Что означает ошибка 'logrotate failed' в выводе cron?

Может ли ошибка logrotate привести к потере логов?

Как отладить конфигурацию logrotate без запуска ротации?

Почему logrotate работает вручную, но падает по cron?

Полезное

Проверьте системные логи на точное сообщение об ошибке

Запустите logrotate вручную в режиме отладки

Проверьте права доступа и владельцев лог-файлов

Убедитесь в наличии свободного места на диске

Проверьте синтаксис конфигурационных файлов

Временное решение: запустите ротацию вручную