LINUX.ORG.RU

Logrotate не обрабатывает часть журналов

 


1

2

Всем привет,

Есть файл /etc/logrotate.d/suricata:

/var/log/suricata/fast.log
/var/log/suricata/http.log
/var/log/suricata/stats.log
{
  daily
  rotate 7
  copytruncate
  compress
  delaycompress
}

Есть файл /etc/logrotate.conf:

weekly
rotate 4
create
include /etc/logrotate.d

/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

Есть файл /etc/cron.daily/logrotate:

#!/bin/sh

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

Ну и, естественно, есть файл /etc/crontab:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

17 * * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6 * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Команда «logrotate -v /etc/logrotate.d/suricata» приводит к требуемому результату. Команда «logrotate -v /etc/logrotate.conf» тоже приводит к требуемому результату. Ротация журналов Suricata по расписанию не работает. Ротация других журналов (в том числе, определённых в /etc/logrotate.d/) работает. В чём может быть причина проблем с журналами Suricata?

★★

Ответ на: комментарий от drBatty

Гм... Не то, чтобы я сомневался в совете... Но просто хотелось бы узнать - какого ожидать результата? Всё может заработать, или нужно посмотреть на какие-то выхлопы после этого?

P.S. А, туплю с утра... Понял.

Cyril ★★
() автор топика
Последнее исправление: Cyril (всего исправлений: 1)
Ответ на: комментарий от drBatty

Узнали. Решил. А теперь колись, в чём суть костыля. Ж;-)

На самом деле, конечно, хотелось бы от него избавиться и сделать так, чтобы в штатной конфигурации работало как надо.

Cyril ★★
() автор топика
Ответ на: комментарий от Cyril

А теперь колись, в чём суть костыля.

можно было-бы и быстрее. Ключ -d ничего не делает, и потому нужен для отладки. Ну и весь вывод я в лог отправил, дабы можно было его читать. Вот и всё.

drBatty ★★
()
Ответ на: комментарий от drBatty

Э-э... Весь вывод я ещё не читал - некогда было. Я о другом - как наличие этой команды, выполняемой каждую минуту, приводит к тому, что начинает нормально работать ротация этих злосчастных журналов?

Cyril ★★
() автор топика
Ответ на: комментарий от Cyril

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

Жаль. Ж;-) Попробую посмотреть, что нужная говорит, конечно.

Cyril ★★
() автор топика
Ответ на: комментарий от drBatty

Кстати - дошли руки, выкинул на фиг ежеминутный костыль. Заодно добавил вывод в журнал для штатного сценария, запускающего logrotate.

Работает. Как надо. Ни фига я в этом не понимаю... Ж:-\

Cyril ★★
() автор топика
Ответ на: комментарий от Cyril

Ни фига я в этом не понимаю...

ну просто налаживать не хочешь. Я ставлю если сейчас 22 минуты запуск каждую 23ю минуту, жду несколько секунд, и читаю лог.

drBatty ★★
()
Ответ на: комментарий от drBatty

Ты не понял. Я убил запуск каждую минуту. Вставил запись в журнал в основной сценарий, который не отрабатывал. Основной сценарий продолжил отрабатывать, вывод у него абсолютно нормальный.

И что тут налаживать? Ошибки то внезапно не стало.

Cyril ★★
() автор топика
Ответ на: комментарий от Cyril

Вставил запись в журнал в основной сценарий, который не отрабатывал.

Ошибки то внезапно не стало.

Как я понимаю, ошибка возникала потому, что было некуда выводить сообщения об ошибке. Crond умеет их отправлять по локальной почте root'у, если это поломать, и при этом не перекинуть вывод хоть куда-нить (/dev/null например, или лог), то команда в crontab рапортует о том, что не смогла вывести информацию.

Звучит бредом, но вот пруф:

$ touch test.file >/xxx
bash: /xxx: Отказано в доступе
$ stat test.file
stat: не удалось выполнить stat для «test.file»: Нет такого файла или каталога
как видишь, команда НЕ выполнилась потому, что ей некуда выводить информацию(хотя она ничего и не выводит).

ЗЫЖ а про logrotate я уже писал на своём форуме.

UPD конечно всё немного не так, у меня ошибка bash'а, который сначала создаёт поток вывод, а потом запускает команду. Создать поток не получилось, ибо нельзя мне писать в rootfs. В итоге bash выдал ошибку ещё до того, как попытался выполнить команду.

drBatty ★★
()
Последнее исправление: drBatty (всего исправлений: 1)
Ответ на: комментарий от drBatty

Может быть. Но надо проверять тогда при случае.

Cyril ★★
() автор топика
Ответ на: комментарий от anarquista

А вот для journald такие костыли не нужны.

конечно не нужны, ведь он гвоздями приколочен к своему бинарному логу.

drBatty ★★
()
Ответ на: комментарий от anarquista

А при чём тут journald? Мы, кажется, не его обсуждаем.

Cyril ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.