¿Por qué mi rotación de CentOS se ejecuta en momentos aleatorios?

Puse un logrotatearchivo de configuración /etc/logrotate.d/y esperaba que los registros giraran en un momento constante; sin embargo, no ... registran tiempos de rotación aparentemente aleatorios +/- una hora.

¿Por qué los tiempos de inicio de rotación de registros son aleatorios y cómo puedo cambiar esto?

/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
}

La clave es saber que CentOS ejecuta los scripts en /etc/cron.{daily,weekly,monthly} from anacron... /etc/anacrontabis setting RANDOM_DELAY, que hace lo que puede esperar (se demora hasta RANDOM_DELAYminutos antes de comenzar el trabajo) ...

# /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

Configuración RANDOM_DELAY=0/ START_HOURS_RANGE=3solucionó el problema ...

EDITAR

Después de pensarlo más, voy a eliminar anacrone instalar vixie normal cron...

No es la respuesta, pero recientemente estaba tratando de resolver esto por otra razón y no pude encontrar ninguna documentación sobre cómo Redhat 6, Centos, etc. ejecutan cron. Esto es lo que realicé en ingeniería inversa:

1. crond todavía se ejecuta al inicio del sistema: carga todos los archivos en /etc/cron.d
2. /etc/cron.d/0hourly ejecuta todos los archivos en /etc/cron.hourly
3. /etc/cron.hourly/0anacron carreras anacron
4. cargas anacron /etc/anacrontab
5. /etc/anacrontabcarreras (a través run-parts) /etc/cron.daily, /etc/cron.weeklyy/etc/cron.monthly

Por lo tanto, es más complicado que en versiones anteriores.

Es posible restaurar el comportamiento anterior agregando las entradas por hora, semanales y mensuales nuevamente /etc/crontab(que ahora está vacío), pero anacrontabtambién deberá actualizarse. Esto puede o no romper futuras actualizaciones ...

Otras respuestas cubren cómo pero no necesariamente por qué . La razón es evitar que los trabajos cron simultáneos nocturnos maten su infraestructura. (Imagine almacenamiento compartido, o quizás 1000 servidores que se ejecutan en un host VM, o solo trabajos nocturnos que afectan a algún servicio en red).

Siempre resuelvo este problema para la rotación de registros específica en mis sistemas moviendo el trabajo de rotación de registros específico de cron.dailyuna entrada con un tiempo codificado cron.d. De esa manera, aún obtienes las ejecuciones escalonadas para servicios como updatedb donde el tiempo realmente no es esencial, sino tiempos consistentes para la rotación de registros.

Por supuesto, cuando llegue a un cierto tamaño, querrá que todos sus registros se envíen del host a un servidor de registros de todos modos, y luego el tiempo de rotación de los archivos en los nodos individuales es menos importante, ya que esos son solo para conveniencia (generalmente siguiendo la cola del archivo) o como recurso de último recurso. Entonces, definitivamente establecería la rotación en su servidor de registro para que sea sistemática.