Warum wird mein CentOS-Logrotate zu zufälligen Zeiten ausgeführt?

Lösung 1:

Der Schlüssel ist zu wissen, dass CentOS die Skripte in /etc/cron.{daily,weekly,monthly} ab anacron ausführt ... /etc/anacrontab setzt RANDOM_DELAY , was das tut, was Sie vielleicht erwarten (es verzögert bis zu RANDOM_DELAY Minuten vor Arbeitsbeginn)...

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

Einstellung RANDOM_DELAY=0 / START_HOURS_RANGE=3 das Problem behoben...

BEARBEITEN

Nach weiterem Nachdenken werde ich anacron entfernen und installiere das normale vixie cron ...

Lösung 2:

Nicht die Antwort, aber ich habe kürzlich versucht, dies aus einem anderen Grund herauszufinden, und konnte keine Dokumentation darüber finden, wie Redhat 6, Centos usw. Cron ausführen. Hier ist, was ich zurückentwickelt habe:

1. crond läuft immer noch beim Systemstart - es lädt alle Dateien in /etc/cron.d
2. /etc/cron.d/0hourly führt alle Dateien in /etc/cron.hourly aus
3. /etc/cron.hourly/0anacron führt anacron aus
4. anacron lädt /etc/anacrontab
5. /etc/anacrontab läuft (über run-parts ) /etc/cron.daily , /etc/cron.weekly und /etc/cron.monthly

Es ist also komplizierter als in früheren Versionen.

Es ist möglich, das alte Verhalten wiederherzustellen, indem die stündlichen, wöchentlichen und monatlichen Einträge wieder in /etc/crontab hinzugefügt werden (der jetzt leer ist), sondern anacrontab muss auch aktualisiert werden. Dies kann zukünftige Updates beeinträchtigen oder auch nicht...

Lösung 3:

Andere Antworten behandeln wie aber nicht unbedingt warum . Der Grund ist es, gleichzeitige nächtliche Cron-Jobs daran zu hindern, Ihre Infrastruktur zu zerstören. (Stellen Sie sich gemeinsam genutzten Speicher oder vielleicht 1000 Server vor, die auf einem VM-Host laufen, oder nur nächtliche Jobs, die einen Netzwerkdienst betreffen.)

Ich löse dieses Problem für die Protokollrotation immer spezifisch auf meinen Systemen, indem ich den spezifischen Protokollrotationsjob von cron.daily verschiebe zu einem Eintrag mit einer fest codierten Zeit in cron.d . Auf diese Weise erhalten Sie immer noch die gestaffelten Läufe für Dienste wie updatedb, bei denen die Zeit wirklich nicht wesentlich ist, aber konsistente Zeiten für die Protokollrotation.

Wenn Sie eine bestimmte Größe erreichen, möchten Sie natürlich, dass alle Ihre Protokolle sowieso vom Host an einen Protokollserver gesendet werden, und dann ist die Rotationszeit der Dateien auf den einzelnen Knoten weniger wichtig, da diese nur dafür da sind Bequemlichkeit (normalerweise nach dem Ende der Datei) oder als letzter Ausweg. Dann würden Sie definitiv Stellen Sie die Rotation auf Ihrem Protokollserver so ein, dass sie systematisch ist.