Proč se moje logrotate CentOS spouští v náhodných časech?

Řešení 1:

Klíčem je vědět, že CentOS spouští skripty v /etc/cron.{daily,weekly,monthly} od anacron ... /etc/anacrontab je nastavení RANDOM_DELAY , který dělá to, co byste mohli očekávat (zpoždění až RANDOM_DELAY minut před zahájením úlohy)...

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

Nastavení RANDOM_DELAY=0 / START_HOURS_RANGE=3 problém vyřešen...

UPRAVIT

Po dalším přemýšlení se chystám odstranit anacron a nainstalujte normální vixie cron ...

Řešení 2:

Ne odpověď, ale nedávno jsem se to snažil zjistit z jiného důvodu a nemohl jsem najít žádnou dokumentaci o tom, jak Redhat 6, Centos atd. spouštějí cron. Zde je to, co jsem zpětně vytvořil:

1. crond stále běží při startu systému - načítá všechny soubory v /etc/cron.d
2. /etc/cron.d/0hourly spouští všechny soubory v /etc/cron.hourly
3. /etc/cron.hourly/0anacron běží anacron
4. anacron načte /etc/anacrontab
5. /etc/anacrontab běží (přes run-parts ) /etc/cron.daily , /etc/cron.weekly a /etc/cron.monthly

Je to tedy složitější než v předchozích verzích.

Je možné obnovit staré chování přidáním hodinových, týdenních a měsíčních záznamů zpět do /etc/crontab (který je nyní prázdný), ale anacrontab bude také nutné aktualizovat. To může nebo nemusí přerušit budoucí aktualizace...

Řešení 3:

Další odpovědi pokrývají jak ale ne nutně proč . Důvod je zabránit souběžným nočním úlohám cron, aby zabily vaši infrastrukturu. (Představte si sdílené úložiště nebo možná 1000 serverů běžících na jednom hostiteli virtuálního počítače nebo jen noční úlohy, které zasáhly nějakou síťovou službu.)

Tento problém s rotací protokolů v konkrétních mých systémech vždy řeším přesunem konkrétní úlohy rotace protokolů z cron.daily na záznam s pevně zakódovaným časem v cron.d . Tímto způsobem stále získáte rozložené běhy pro služby, jako je updatedb, kde čas opravdu není podstatný, ale konzistentní časy pro rotaci protokolu.

Samozřejmě, když dosáhnete určité velikosti, budete chtít, aby se všechny vaše protokoly stejně odeslaly z hostitele na protokolovací server, a pak je doba rotace souborů na jednotlivých uzlech méně důležitá, protože ty jsou tam jen pro pohodlí (obvykle po konci souboru) nebo jako záložní řešení poslední možnosti. Pak byste určitě nastavte rotaci na vašem log serveru tak, aby byla systematická.