Re: [opensuse] logrotate and crontab



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:grahamsmith@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
tel;cell:07876793607
version:2.1
end:vcard



Relevant Pages