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

Проверка на конфликт logrotation параметры конфигурации!!

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

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

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

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

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

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

У меня была аналогичная проблема, но 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 вручную (или запускать /etc/cron.daily , и он просто отлично их вращает.

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

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

Чтобы дать вам представление, последнее исправление касалось того, что параметр notifyempty в файле 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 и посмотрите, что происходит в этой папке (если что-нибудь).

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

Просто подумал, что если в поисках она все еще получится достаточно высокой, то я внесу свой вклад и дам свое решение проблемы, с которой столкнулся. Мои задания по логротату не обрабатывались автоматически на одном из моих серверов. Принудительное вращение работало нормально. Я придумал решение после того, как запустил команду daily rotation by hand:

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

Затем я увидел ошибку, которая остановила работу lograte:

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

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

rm /etc/logrotate.d/iptraf

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

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