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.
begin:vcard
fn:Graham T. Smith
n:Smith;Graham T.
adr:Barton upon Humber;;90 Bowmandale;;North Lincs.;DN18 5EA;UK
email;internet:[EMAIL PROTECTED]
tel;cell:07876793607
version:2.1
end:vcard

Reply via email to