Perché il mio CentOS logrotate viene eseguito in momenti casuali?

Soluzione 1:

La chiave è sapere che CentOS esegue gli script in /etc/cron.{daily,weekly,monthly} da anacron ... /etc/anacrontab sta impostando RANDOM_DELAY , che fa quello che ci si potrebbe aspettare (ritarda fino a RANDOM_DELAY minuti prima di iniziare il lavoro)...

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

Impostazione RANDOM_DELAY=0 / START_HOURS_RANGE=3 risolto il problema...

MODIFICA

Dopo ulteriori riflessioni, rimuoverò anacron e installa il normale vixie cron ...

Soluzione 2:

Non è la risposta, ma di recente stavo cercando di capirlo per un altro motivo e non sono riuscito a trovare alcuna documentazione su come Redhat 6, Centos, ecc. Eseguono cron. Ecco cosa ho decodificato:

1. crond funziona ancora all'avvio del sistema - carica tutti i file in /etc/cron.d
2. /etc/cron.d/0hourly esegue tutti i file in /etc/cron.hourly
3. /etc/cron.hourly/0anacron esegue anacron
4. anacron carica /etc/anacrontab
5. /etc/anacrontab esegue (tramite run-parts ) /etc/cron.daily , /etc/cron.weekly e /etc/cron.monthly

Quindi, è più complicato rispetto alle versioni precedenti.

È possibile ripristinare il vecchio comportamento aggiungendo nuovamente le voci orarie, settimanali e mensili in /etc/crontab (che ora è vuoto), ma anacrontab dovrà essere aggiornato anch'esso. Questo potrebbe interrompere o meno i futuri aggiornamenti...

Soluzione 3:

Altre risposte riguardano come ma non necessariamente perché . Il motivo è impedire che i lavori cron notturni simultanei uccidano la tua infrastruttura. (Immagina l'archiviazione condivisa, o forse 1000 server in esecuzione su un host VM, o solo lavori notturni che colpiscono un servizio di rete.)

Risolvo sempre questo problema per la rotazione dei log in modo specifico sui miei sistemi spostando il lavoro di rotazione dei log specifico da cron.daily a una voce con un tempo hard-coded in cron.d . In questo modo, ottieni comunque le esecuzioni sfalsate per servizi come updatedb in cui l'ora non è davvero essenziale, ma tempi coerenti per la rotazione dei log.

Ovviamente, quando raggiungi una certa dimensione, vorrai comunque che tutti i tuoi log vengano inviati dall'host a un server di log, e quindi il tempo di rotazione dei file sui singoli nodi è meno importante, poiché quelli sono lì solo per convenienza (di solito seguendo la coda del file) o come ripiego di ultima istanza. Allora, lo faresti sicuramente imposta la rotazione sul tuo server di registro in modo che sia sistematica.