Solution 1 :
La clé est de savoir que CentOS exécute les scripts dans /etc/cron.{daily,weekly,monthly} à partir de anacron ... /etc/anacrontab définit RANDOM_DELAY , qui fait ce que vous pourriez attendre (il retarde jusqu'à RANDOM_DELAY minutes avant de commencer le travail)...
# /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
Réglage RANDOM_DELAY=0 / START_HOURS_RANGE=3 a résolu le problème...
MODIFIER
Après réflexion, je vais supprimer anacron et installez vixie normal cron ...
Solution 2 :
Ce n'est pas la réponse, mais j'ai récemment essayé de comprendre cela pour une autre raison et je n'ai trouvé aucune documentation sur la façon dont Redhat 6, Centos, etc. exécutent cron. Voici ce que j'ai rétro-conçu :
crondfonctionne toujours au démarrage du système - il charge tous les fichiers en/etc/cron.d/etc/cron.d/0hourlyexécute tous les fichiers en/etc/cron.hourly/etc/cron.hourly/0anacronexécuteanacron- anacron charge
/etc/anacrontab /etc/anacrontabs'exécute (viarun-parts)/etc/cron.daily,/etc/cron.weeklyet/etc/cron.monthly
Du coup, c'est plus compliqué que dans les versions précédentes.
Il est possible de restaurer l'ancien comportement en ajoutant les entrées horaires, hebdomadaires et mensuelles dans /etc/crontab (qui est maintenant vide), mais anacrontab devra être mis à jour aussi. Cela peut ou non interrompre les futures mises à jour...
Solution 3 :
D'autres réponses couvrent comment mais pas nécessairement pourquoi . La raison est d'empêcher les tâches cron nocturnes simultanées de tuer votre infrastructure. (Imaginez un stockage partagé, ou peut-être 1 000 serveurs exécutés sur un hôte VM, ou simplement des tâches nocturnes qui touchent un service en réseau.)
Je résous toujours ce problème de rotation des journaux en particulier sur mes systèmes en déplaçant le travail de rotation des journaux spécifique de cron.daily à une entrée avec une heure codée en dur en cron.d . De cette façon, vous obtenez toujours les exécutions échelonnées pour des services comme updatedb où le temps n'est vraiment pas essentiel, mais des temps cohérents pour la rotation des journaux.
Bien sûr, lorsque vous atteignez une certaine taille, vous voudrez de toute façon que tous vos journaux soient envoyés de l'hôte vers un serveur de journaux, puis le temps de rotation des fichiers sur les nœuds individuels est moins important, car ceux-ci ne sont là que pour commodité (généralement en fin de fichier) ou en dernier recours. Alors, vous feriez certainement paramétrez la rotation sur votre serveur de logs pour qu'elle soit systématique.