logrotate не будет автоматически вращать мои журналы

У меня была аналогичная проблема, но crontab работал и для некоторых каталогов журналов logrotate работал, но для некоторых нет. Когда я попытался запустить logrotate вручную, я получил несколько сообщений об ошибках.

user@server:/var/log/apache2$ sudo /usr/sbin/logrotate -f /etc/logrotate.conf
error: error creating output file /var/log/apache2/access.log.1.gz: File exists
error: error creating output file /var/log/apache2/error.log.1.gz: File exists
...

Все из *.1.gz файлы имели размер 0. Я вручную удалил все файлы, упомянутые в сообщении об ошибке, запустил sudo /usr/sbin/logrotate -f /etc/logrotate.conf снова, и это сработало.

Я просто хотел бы поделиться этим альтернативным решением и здесь, поскольку это был первый результат поиска, который пришел ко мне, когда я искал проблему, но предложенное решение не сработало для меня. Может быть, это поможет и другим, находящимся в той же ситуации, что и я.

Убедитесь, что ваш logrotate запускается cron.

Редактировать:

Из обсуждения комментария - похоже, что cron работает некорректно. У меня было задание cron в моем crontab без пользователя, но это обнаружилось только при перезапуске демона cron

Мои системы ubuntu и centos имеют /etc/cron.daily/logrotate файл, содержимое которого

#!/bin/sh

test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf

В моем / etc / crontab есть следующая строка для выполнения ежедневных заданий

25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily 

Я знаю я знаю. 5-летняя нить.

Просто подумал, что если это все еще будет довольно популярно в поиске, я внесу свой вклад и предложу свое решение проблемы, с которой я столкнулся. Мои задания logrotate не обрабатывались автоматически на одном из моих серверов. Принудительное вращение работало нормально. Я придумал решение после того, как вручную запустил команду ежедневной ротации:

( cd / && run-parts --report /etc/cron.daily )

Затем я увидел ошибку, из-за которой задания логрорейтинга не запускались:

/etc/cron.daily/logrotate:
error: iptraf-ng:2 duplicate log entry for /var/log/iptraf/*.log

Да, вот так просто. У меня было два файла, определяющих одинаковые журналы для ротации (iptraf и iptraf-ng). Просто удалите одно из конфликтующих определений logrotate для iptraf.

rm /etc/logrotate.d/iptraf

Другой проблемой может быть испорченный файл / etc / crontab. Это означает двойную или тройную проверку синтаксиса этого файла, поскольку он не дает никаких результатов, которые я мог бы найти, если синтаксис неправильный. Тихо завершает работу после неудачной проверки синтаксиса.

Надеюсь, это кому-то сэкономит время.

ОК, у меня была аналогичная проблема.

"журналы не вращаются?" но запустив logrotate вручную (или запустив /etc/cron.daily и он их просто отлично вращает.

Получается, что cron просто «не работает» каждый день. Странный. Итак, я посмотрел в файл журнала, где cron выводит свои данные и увидел, что «Маркер аутентификации больше не действителен; требуется новый», чтобы исправить эту конкретную проблему, см. Вот

Я наблюдал, как это часто происходило с течением времени, когда сервисы менялись, а параметры, используемые в logrotate, были отредактированы, что приводило к сбоям logrotate каждый день.

Чтобы дать вам представление, последнее исправление касалось уведомить опция в файле apache logrotate больше не действует, что, в свою очередь, приводит к остановке logrotate.

Хотя это уже было рассмотрено до определенного момента, я хотел бы поделиться процессом, который я прохожу при отслеживании этих проблем:

1. начать с бега #/usr/sbin/logrotate -f /etc/logrotate.conf для поиска ошибок (например, postfix: 3 'missingok'.)
   Номер файла и строки, на которые он ссылается, - это файл в папке logrotate.d.
2. Отредактируйте рассматриваемый файл: # vi /etc/logrotate.d/postfix, и удалите параметр, вызывающий проблему, и сохраните файл.
3. Повторите первый шаг, чтобы увидеть, работает ли ротация или есть другие проблемы.

Бывают случаи, когда первый шаг просто выводит что-нибудь, но вы знаете, что есть проблема. Поскольку все это началось из-за того, что файлы журнала для службы не вращались, вы можете наблюдать, как процесс logrotate ищет эту конкретную службу, чтобы узнать, что мешает ей вращаться. Для этого добавьте подробный тег в свою команду logrotate и посмотрите, что происходит в этой папке (если что-нибудь).

Проверьте наличие конфликтующих параметров конфигурации logrotation !!

Я боролся с этой проблемой и, наконец, очень внимательно прочитал некоторую документацию по logrotate, я нашел полезную документацию Вот.

Я указал как Размер параметр и Интервал вращения параметр, хотя на самом деле я не хотел ни того, ни другого. Я хотел, чтобы мои ротации происходили именно тогда, когда они были запланированы в cron.

1. Размер параметр переопределит любой интервал вращения. Поэтому мои журналы должны были превысить этот параметр, прежде чем они когда-либо были повернуты. (Я понимаю, как это было бы полезно, когда вы больше всего беспокоились об использовании диска. Но я хотел использовать это не так.)
2. Интервал вращения проверит, когда произошло последнее вращение, и убедится, что следующее вращение задерживается на указанную величину. Но мне неясно, как вы контролируете, когда наступает это время, это основано на том, когда в последний раз произошла ротация.

Итак, избавьтесь от Интервал вращения и Размер параметр. Тогда вы будете получать ротацию каждый раз, когда вызывается logrotate, без необходимости принудительно.

РЕДАКТИРОВАТЬ: OK даже это не совсем работает! Если размер файла журнала ниже определенного порога, журналы не будут чередоваться. Поэтому, когда я запускал задание cron, которое менялось каждые 2 минуты, оно не меняло журналы.

Вы можете увидеть подробную информацию об отладке, если запустите logrotate -d. Это дает очень полезную информацию об отладке.