Carlos E. R. wrote:
The Thursday 2007-03-29 at 11:08 -0300, Rejaine Monteiro wrote:
as far as i can see, the default crontab entries (in /etc/cron.daily, etc/cron.hourly etc.) are being scheduled via the /etc/crontab master file:
-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 14 4 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 4 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly
but at what time does for example /etc/cron.daily/* get run ?
No, there is no fixed time.
The logic has changed a bit from version to version, but in a system that is on 24/7 hours, it was supposed to always runs at the same time that the previous day, whichever that is. If when that hour passes the system is off, then it will run within 15 minutes of being powered up, and at the same time thereafter every day.
This is so except for a bug in... 9.3? where the time shifted 15 minutes every day.
it's important for me because i want to schedule sarg (squid statistics generator) at 2 pm and i want to be sure that i always run logrotate (to rotate squid logs) exactly might.
Then, if you need an exact hour, you need to move out your job from cron.daily, and schedule it directly in cron.
Alternatively, there is a trick touching or removing the flag file (not sure which at the moment) file two minutes before the time you want it to run.
In 10.2 it appears to have changed a bit. The cron entries above actually delete the flag at a precise time (4:16 daily), so it would cause the daily run to run at that time, at least.
But this is not exactly so, there is a new variable in "/etc/sysconfig/cron":
# Type: time (eg: 14:00) # Default: nothing # # At which time cron.daily should start. Default is 15 minutes after booting # the system. Due to the fact that cron script runs only every 15 minutes, # it will only run on xx:00, xx:15, xx:30, xx:45, not at the accurate time # you set. DAILY_TIME=""
# Type: integer (days) # Default: 5 # # Maximum days not running when using a fixed time set in DAILY_TIME. # 0 to skip this. This is for users who will power off their system. # # There is a fixed max. of 14 days set, if you want to override this # change MAX_NOT_RUN_FORCE in /usr/lib/cron/run-crons MAX_NOT_RUN="5"
Mmmm.... they have changed this quite a bit. What I said first does not exactly apply to 10.2, only to previous versions. I'll have to study it over again.
The drift in 9.3 I experienced, so I modified the run-cron script which actually processes the contents /etc/cron.<time> directories to enforce hourly, daily and monthly cron jobs at appropriate times for me. Had a look at new run-cron script to establish how sysconfig bits are working with it, and it has a serious kludge factor. The underlying design of run-crons is very good, but the treatment of this variable is a little ugly. (A lot of timedate syntax checks that need to be done because the YaST sysconfig editor does no data input validation with dates ... !!SuSE YaST people think about it!!). Cheap nasty short cut was to touch the lock files with whatever time one wanted things to happen.