¿Por qué mi logrotate de CentOS se ejecuta en momentos aleatorios?

Solución 1:

La clave es saber que CentOS ejecuta los scripts en /etc/cron.{daily,weekly,monthly} desde anacron ... /etc/anacrontab está configurando RANDOM_DELAY , que hace lo que cabría esperar (retrasa hasta RANDOM_DELAY minutos 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

Ajuste RANDOM_DELAY=0 / START_HOURS_RANGE=3 solucionado el problema...

EDITAR

Después de pensarlo más, voy a eliminar anacron e instale vixie normal cron ...

Solución 2:

No es la respuesta, pero recientemente intenté 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 hice ingeniería inversa:

1. crond todavía se ejecuta al iniciar el 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 ejecuta anacron
4. anacron carga /etc/anacrontab
5. /etc/anacrontab se ejecuta (a través de run-parts ) /etc/cron.daily , /etc/cron.weekly y /etc/cron.monthly

Entonces, es más complicado que en versiones anteriores.

Es posible restaurar el comportamiento anterior agregando las entradas por hora, semanales y mensuales nuevamente en /etc/crontab (que ahora está vacío), pero anacrontab tendrá que ser actualizado también. Esto puede o no interrumpir futuras actualizaciones...

Solución 3:

Otras respuestas cubren cómo pero no necesariamente por qué . La razón es evitar que los trabajos cron nocturnos simultáneos eliminen su infraestructura. (Imagínese almacenamiento compartido, o tal vez 1000 servidores ejecutándose en un host de VM, o simplemente trabajos nocturnos que afectan a algún servicio en red).

Siempre resuelvo este problema para la rotación de registros en específico en mis sistemas moviendo el trabajo de rotación de registros específico de cron.daily a una entrada con un tiempo codificado en cron.d . De esa forma, aún obtendrá ejecuciones escalonadas para servicios como updatedb, donde el tiempo realmente no es esencial, sino tiempos constantes 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 registro de todos modos, y luego el tiempo de rotación de los archivos en los nodos individuales es menos importante, ya que están ahí para conveniencia (generalmente siguiendo la cola del archivo) o como último recurso alternativo. Entonces, definitivamente configure la rotación en su servidor de registro para que sea sistemática.