Не отрабатывает logrotate
Коллеги, добрый день. Помогите пожалуйста. Настроил logrotate для squid, но он не хочет работать, не понимаю почему.
Я что-то упустил и дополнительно нужно где-то настроить удаление старых файлов?
Попробовал принудительно выполнить очистку через logrotate -f /etc/logrotate.d/squid -d. Вижу что скрипт отрабатывает:
Но в директориях старые файлы остаются, ничего не удаляется.
Все верно и я не так понял принцип работы logrotate или все же файлы должны быть удалены?
Почистил всю папку сам, оставил только access.log и cache.log в соответствующих папках. Еще раз запустил logrotate вручную. Непонятно почему в логе четко написано renaming /ClFS/squid/logs/access.log to /ClFS/squid/logs/access.log.1, и так же для cache.log, но в папках остались только access.log и cache.log — ничего не переименовалось и не создалось.
logrotate удаляет только те файлы, в пределах которых он работает. Т.е. если раньше не было параметра compress, то создавались файлы вида *.1, *.2, вот такие и удалялись бы. Теперь есть compress, значит удаляться будут *.1.gz, *.2.gz, а на несжатые он внимания не обращает.
Когда происходит ротация лога, он переименовывается в какой-то, если другой лог с таким именем уже есть, тогда logrotate переключается на переименование этого другого. И так далее, пока не дойдёт до лимита переименований (rotate N). Вот последний он уже не переименовывает, а удаляет.
Любые другие файлы, не участвующие в этом процессе, logrotate не замечает. Т.е., например, access.log.06-09.09 не удалится никогда, нужно чистить вручную.
Спасибо, стало немного понятнее. Но по идее, если я почистил всё, оставив только access.log и cache.log, то при запуске
Почитал еще несколько тем с аналогичной проблемой, там у людей logrotate просто внезапно начинал работать. Не знаю, может у меня завтра всё станет нормально после ручной чистки лишнего.
Не знаю, может у меня завтра всё станет нормально после ручной чистки лишнего.
Если только тестируете можно не ждать, просто поправить цифирки вот здесь /var/lib/logrotate/status
Ещё в logrotate есть такой момент, как обработка новых логов: если какой-то лог добавляется в обработку впервые, для него в /var/lib/logrotate/status (или /var/lib/logrotate.status) ещё нет пометки с датой. Поэтому при первом запуске logrotate ротацию этого лога не выполняет, просто ставит пометку, а уже при последующих делает ротацию.
Запуск через logrotate -f /etc/logrotate.d/squid не совсем корректный, т.к. при этом не читаются настройки из общего /etc/logrotate.conf.
Также при проблемах помогает просмотр ошибок в режиме отладки:
Не, это сервер в проде, на нём 3к юзеров. Сегодня проверил — пока в папке есть основной access.log и 5 файлов .log.0, log.1.gz, log.2, log.2.gz и log.3. Завтра еще проверю, надеюсь количество не вырастет.
Большое всем спасибо за помощь!
К сожалению, не заработало. За эти дни накопились вот такие файлы:
Источник
Logrotate не работает
Я пытаюсь заставить logrotate работать на моем VPS, чтобы еженедельно вращать мои файлы apache. В настоящее время содержимое файла конфигурации apache2 как таковое.
Я оставил его на две недели, и, насколько я могу судить, ничего не изменилось. Когда я имитирую это из командной строки, я получаю следующий вывод.
Любые идеи относительно того, что Iv’e настроен неправильно?
Мой файл статуса тоже пуст 🙁
Обновить
Я удалил файл состояния и сделал принудительный запуск logrotate, и теперь журналы выглядят так, как будто они повернуты, а файл состояния выглядит более многообещающе!
Я думаю, это weekly означает, что logrotate хочет увидеть как минимум недельную запись для вашего файла access.log, чтобы повернуть его.
Следовательно, проблема заключается в том, что вы не сохраняете запись состояния для запуска вращения.
Вот пошаговый пример простого случая, когда logrotate решает повернуть файл журнала
(это пути fedora, Ubuntu, Centos и т. Д. Могут отличаться)
(Я сделал несколько запросов, чтобы http://localhost в access_log было несколько записей, иначе logrotate никогда не вращается . )
Таким образом, я установил свой logrotate для Apache еженедельно, вот так;
и изначально нет записи в /var/lib/logrotate.status файле
Таким образом, logrotate не вращает access_log файл;
Однако, если я запускаю logrotate вручную, вот так;
теперь в файле состояния есть запись для httpd access_log;
Однако apache все еще не собирается вращать журнал, потому что запись только 0 дней (2012-5-11);
Однако, если вы редактируете файл состояния с помощью vi, вы vi /var/lib/logrotate.status должны установить дату более недели . ;
Тогда logrotate теперь корректно поворачивает файл, поскольку дата в файле состояния 2012-4-11 больше недели назад с сегодняшнего дня. 2012-5-11
(имейте в виду, что -d причины пробного прогона, следовательно, полезны только для проверки, вы должны фактически выполнить команду без -d внесения записей состояния или поворота файлов и т. д.)
Это может быть из-за того, что ваши файлы журнала пусты.
Это может произойти из-за того, что apache все еще записывает предыдущий файл журнала, который был переименован без перезапуска apache. Таким образом, access.log стал access.log.1, и apache пишет в него.
Или у вас есть проблемы со временем создания журнала:
Я столкнулся с подобной проблемой, за исключением того, что ни один из этих ответов не помог мне. Мой файл журнала был огромным и старым, моя конфигурация была на 100% в порядке и действительна, удаление файла состояния не помогло.
Выяснилось, что проблема заключалась в дублировании записей logrotate . Когда я запускаю logrotate вручную в моем конфигурационном файле только так:
он не показал никаких ошибок, он просто сказал:
Я до сих пор не знаю, почему на самом деле. Но когда я запускаю полную команду logrotate, вот так:
Я получил следующую строку:
Оказалось, что файл конфигурации logrotate для моей службы содержит записи для ротации журналов доступа nginx, а также сами журналы службы. И это противоречило конфигурации ngnix logrotate, в которой есть правило для всех записей nginx:
Поэтому решение для моего случая довольно простое: мне просто нужно было удалить конфликтующее правило ротации журналов nginx из моей конфигурации .
Я полагаю, что logrotate начал прерывать обработку файла при конфликтах правил только из одной из новейших версий. Я получаю эту ошибку с v.3.8.7, но под v.3.7.8 с той же конфликтующей конфигурацией выдает ту же ошибку, но вращается нормально. Хотя я не смог найти ни одной записи об этом в журнале изменений logrotate.
Источник
Логротат не работает
Я пытаюсь заставить logrotate работать на моем VPS для поочередного вращения файлов apache. В настоящее время содержимое файла конфигурации apache2 как таковое.
Я оставил его в течение двух недель, и ничто не изменилось, насколько я могу судить. Когда я имитирую его из командной строки, я получаю следующий вывод.
Любые идеи относительно того, что Iv’e настроено неправильно?
Мой файл статуса также пуст: (
Обновить
Я удалил файл состояния и выполнил команду runrotate, и теперь журналы выглядят так, как будто они были повернуты, и файл статуса выглядит более перспективным!
5 ответов
Я думаю, что weekly означает, что logrotate хочет увидеть хотя бы недельную запись для вашего файла access.log, чтобы повернуть он.
Следовательно, проблема заключается в том, что вы не сохраняете запись состояния для запуска вращения.
Вот примерный пример простого случая, как logrotate решает повернуть файл журнала
(это пути Fedora, Ubuntu, Centos и т. д. могут быть разными)
(Я сделал несколько запросов к http://localhost , поэтому в access_log есть некоторые записи, иначе logrotate никогда не вращается . )
Итак, я установил свой логротат для apache как еженедельно,
и изначально в файле /var/lib/logrotate.status нет записи
Таким образом, logrotate не вращает файл access_log ;
Однако, если я запускаю logrotate вручную так:
теперь есть запись в файле состояния для httpd access_log;
Однако apache все равно не собирается вращать журнал, потому что запись только 0 дней (2012-5-11);
Однако, если вы редактируете файл состояния с vi vi /var/lib/logrotate.status , чтобы что-то вроде этого, чтобы установить дату более чем на неделю . ;
Затем logrotate теперь корректно поворачивает файл из-за даты в файле состояния 2012-4-11 более недели назад с сегодняшнего дня 2012-5-11
(помните, что -d вызывает сухость, поэтому полезен только для проверки, вы должны фактически запустить команда без -d , чтобы сделать записи состояния или повернуть файлы и т. д.)
Это может быть связано с тем, что файлы журналов пусты.
Такая ситуация может произойти из-за того, что apache все еще записывает в предыдущий файл журнала, который был переименован без перезапуска apache. Таким образом access.log стал access.log.1, и apache пишет в него.
Или у вас возникла проблема со временем создания журнала:
Я столкнулся с подобной проблемой, за исключением того, что ни один из этих ответов не помог мне. Мой файл журнала был огромным и старым, моя конфигурация была на 100% нормально и действительна, удаление файла состояния не помогло.
Оказалось, что проблема заключалась в дублировании записей logrotate . Когда я запускаю logrotate вручную в моем файле конфигурации только так:
в нем не было никаких ошибок, он просто сказал:
Я до сих пор не знаю, почему на самом деле. Но когда я запускаю полную команду logrotate:
Я получил следующую строку:
Оказалось, что файл конфигурации logrotate для моей службы содержит записи для вращения журналов доступа nginx, а также журналы служб. И это противоречило конфигурации ngnix logrotate, которая имеет правило для всех записей nginx:
Итак, решение для моего дела довольно просто: мне просто нужно было удалить конфликтующее правило nginx logs вращения из моей конфигурации .
Я предполагаю, что logrotate начал прервать обработку файла при конфликтах правил только с одной из новейших версий. Я получаю эту ошибку с v.3.8.7, но в соответствии с v.3.7.8 с той же конфликтной конфигурацией он записывает ту же ошибку, но вращается нормально. Хотя я не мог найти записи об этом в журнале изменений logrotate.
Источник
Cron не стартует logrotate
Всем привет. Появилась необходимость, создать ротацию лог файла, так как уж больно аудит забивает логи. конфиг /etc/logrotate.d/parsec выглядит следующим образом:
Что-то у вас много нестыковок. Сейчас скрипты из /etc/cron.daily запускаются anacron’ом. Потом если файл большого размера и вы ограничиваете его размер, то тогда нужно запускать не раз в день, а чаще. И обычно пишущему процессу посылают сигнал, а не restart, и в любом случае, после ротации файла, а не до (то есть postrotate).
Извиняюсь, напутал с конфигом. На деле он следующего вида.
Не совсем. Просто проверка размера файла происходит только в момент вызова logrotate. Если запускать logrotate раз в сутки, то указание размера смысла не имеет, будет срабатывать ″daily″.
Если данных в лог пишется много и хочется как-то ограничить размер, то нужно вызывать logrotate чаще. Хотя 2к это совсем мало — один экран текста.
Прочитайте что-нибудь про команды sh (bash). Эта строка проверяет наличие исполняемого файла anacron и если он есть ничего не делает. То есть, если anacron есть, то он запускает задачи из /etc/cron.daily, при условии, что не редактировался дефолтный конфиг в /etc/anacrontab и не удалялся файл /etc/cron.hourly/0anacron.
И anacron не запускает задание прямо в 6:25, он запускает у указанный в конфиге промежуток времени.
Можете поместить скрипт logrotate в /etc/cron.hourly или отредактировать /etc/crontab, чтобы logrotate запускался раз в час.
Допустим в конфиге ротации у меня указан параметр daily. Если перенести его в cron.hourly, то будет ли происходить ротация каждый час, если указан параметр daily?
Нет, часовой ротации не будет. Будет ротация по размеру файла (если он указан).
Logrotate parsec
Rayman привет, получилось ли решить данную проблему, столкнулся с такой же темой, на астре 1.5 parsec сыпит лог как бешенный, а logrotate ну никак не хочет ротировать.
привет! Да получилось, вот Здесь хорошо описано
Источник
Настройка Logrotate
В Linux, большинство сервисов и программ, которые работают в фоне, таких как Apache, Nginx, Postfix и других записывают информацию о своем состоянии, результатах работы и ошибках в лог файлы. Стандартное расположение логов или как их еще называют — журналов — в папке /var/log.
С помощью анализа логов вы можете понять что работает не так, почему произошла ошибка и как решить возникшую проблему. Но тот кроется одна проблема. Размер логов постоянно растет и они занимают все больше и больше места на диске, поэтому необходимо вовремя чистить логи и удалять устаревшие записи, чтобы они не мешали нормально работать. Это можно делать вручную время от времени или настроить скрипты Cron, но есть еще более простой вариант — утилита logrotate. В этой статье будет рассмотрена настройка logrotate и ее использование.
Как работает Logrotate?
Утилита Logrotate предназначена для автоматизации обработки журналов. Она может выполнять с ними необходимые действия в зависимости от определенных условий и правил соответствия. Например, можно сжимать журналы в архив или отправлять на другой сервер когда они достигают определенного размера, возраста, или других параметров.
Проверку условий можно настроить ежедневно, еженедельно или ежемесячно. Это позволяет создать схему ротации логов, удобную именно для вас и вашего сервера. Также ротация логов может быть полезна на домашнем компьютере, но здесь она не так важна как на серверах, где только в логи Apache могут записываться до сотен тысяч строк ежедневно.
Настройка Logrotate
Logrotate — это популярная утилита, поэтому в большинстве дистрибутивов она поставляется по умолчанию. Вы можете убедиться, что программа установлена в вашем дистрибутиве, попытавшись ее установить. Например, в CentOS:
sudo yum install logrotate
Или в Ubuntu и основанных на ней дистрибутивах:
sudo apt install logrotate
Теперь, даже если утилита не была установлена, вы ее установите. Все основные настройки программы находятся в файле /etc/logrotate.conf, дополнительные настройки, касаемо правил и других возможностей могут быть размещены в папке /etc/logroate.d/. Вы можете размещать все настройки logroatae прямо в основном конфигурационном файле, будет более правильно, если настройки для каждого отдельного сервиса будут находиться в отдельном файле, в папке /etc/logrotate.d/.
Чтобы конфигурационные файлы из этой папки загружались программой, необходимо добавить в основной конфигурационный файл такую строчку:
Просто убедитесь что она там уже есть. Сначала давайте рассмотрим основные директивы, которые мы будем применять во время настройки. Здесь директивы выглядят не совсем обычно, сама директива и определяет что и когда нужно делать, а уже если нужно, ей передаются дополнительные параметры. Чтобы указать как часто нужно выполнять проверку совпадению условий используются такие директивы:
- hourly — каждый час;
- daily — каждый день;
- weekly — каждую неделю;
- monthly — каждый месяц;
- yearly — каждый год.
Основные директивы управления и обработки логов:
- rotate — указывает сколько старых логов нужно хранить, в параметрах передается количество;
- create — указывает, что необходимо создать пустой лог файл после перемещения старого;
- dateext — добавляет дату ротации перед заголовком старого лога;
- compress — указывает, что лог необходимо сжимать;
- delaycompress — не сжимать последний и предпоследний журнал;
- extension — сохранять оригинальный лог файл после ротации, если у него указанное расширение;
- mail — отправлять Email после завершения ротации;
- maxage — выполнять ротацию журналов, если они старше, чем указано;
- missingok — не выдавать ошибки, если лог файла не существует;
- olddir — перемещать старые логи в отдельную папку;
- postrotate/endscript — выполнить произвольные команды после ротации;
- start — номер, с которого будет начата нумерация старых логов;
- size — размер лога, когда он будет перемещен;
Это те основные директивы, которые мы будем использовать. В главном конфигурационном файле находится глобальная конфигурация, директивы, которые будут распространяться на все логи если не было отменено их действие. Каждый лог, который подлежит ротации описывается таким образом:
адрес_файла_лога <
директивы
>
Теперь давайте создадим файл rsyslog.conf в папке /etc/logrotate.d/ и поместим в него настройки для ротации этого лога:
/var/log/messages <
daily
rotate 3
size 10M
compress
delaycompress
>
Эти настройки означают, что ротация журналов будет выполняться ежедневно, и мы будем хранить три последних журнала, более старые копии будут автоматически удаляться. Минимальный размер для ротации — 10 мегабайт, ротация не будет выполнена, если лог не занимает более 10 мегабайт. Будет использоваться сжатие, для всех журналов кроме последнего и предпоследнего. Точно по такому же принципу вы можете настроить ротацию логов для любого из журналов. Нужно создать такую секцию для каждого из логов, которыми вы хотите управлять.
Теперь осталось протестировать как работает наша конфигурация. Для этого запустим утилиту logrotate с опцией -d. Она выведет все, что планируется сделать, но не будет изменять файлы на диске. У нас есть файл /var/log/messages, размером 40 Мегабайт, посмотрим что будет делать утилита:
logrotate -d /etc/logrotate.d/rsyslog.conf
Как видите, программа обнаруживает файл лога и разделяет его на несколько частей. Вы можете убедиться, что logrotate будет запускаться как положено проверив расписание cron:
Настройка Logrotate завершена, а вам осталось всего лишь расписать как будет выполняться ротация логов для каждого из журналов, которые занимают много места.
Выводы
В этой статье мы рассмотрели как выполняется настройка logrotate centos или в любом другом дистрибутиве Linux. Работа утилиты не сильно отличается в зависимости от дистрибутивов. Если у вас есть сервер с большой нагрузкой, вам обязательно необходимо настроить ротацию логов. Надеюсь, эта информация была полезной для вас. На завершение видео, о том как выполняется ротация логов в Ubuntu от LPIC:
И еще одно на английском:
Источник