Назад | Перейти на главную страницу

Почему мой CentOS logrotate запускается в случайное время?

Я поставил logrotate файл конфигурации в /etc/logrotate.d/ и ожидал, что бревна будут вращаться в определенное время; однако они не ... время ротации журнала кажется случайным +/- один час.

Почему время начала ротации журнала случайное и как это изменить?

Informational: my logrotate config file looks like this...

/opt/backups/network/*.conf {
        copytruncate
        rotate 30
        daily
        create 644 root root
        dateext
        maxage 30
        missingok
        notifempty
        compress
        delaycompress
        postrotate
            ## Create symbolic links in daily/
            PATH=`/usr/bin/dirname $1`;
            FILE=`/bin/basename $1`;
            /bin/ln -s $1 $PATH/daily/$FILE
        endscript
}

Ключ в том, чтобы знать, что CentOS запускает скрипты в /etc/cron.{daily,weekly ,monthly} из anacron... /etc/anacrontab устанавливает RANDOM_DELAY, что делает то, что вы ожидаете (задержка до RANDOM_DELAY минут до начала работы) ...

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly

Настройка RANDOM_DELAY=0 / START_HOURS_RANGE=3 исправил проблему ...

РЕДАКТИРОВАТЬ

Поразмыслив, я собираюсь удалить anacron и установи нормальную викси cron...

Не ответ, но недавно я пытался понять это по другой причине и не смог найти никакой документации о том, как Redhat 6, Centos и т. Д. Запускают cron. Вот что я реконструировал:

  1. crond все еще работает при запуске системы - загружает все файлы в /etc/cron.d
  2. /etc/cron.d/0hourly запускает все файлы в /etc/cron.hourly
  3. /etc/cron.hourly/0anacron бежит anacron
  4. анакрон загружает /etc/anacrontab
  5. /etc/anacrontab проходит (через run-parts) /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly

Итак, это сложнее, чем в предыдущих версиях.

Можно восстановить прежнее поведение, добавив почасовые, еженедельные и ежемесячные записи обратно в /etc/crontab (который сейчас пуст), но anacrontab тоже нужно будет обновить. Это может или не может нарушить будущие обновления ...

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

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

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