On Sunday 01 July 2007, Ryan Reich wrote: > This is a small essay on Gentoo's setup for fcron.
which is troublesome because some of the things here are specific to fcron
(which frankly dont interest me) while others are specific to the cronbase
package which installs `run-crons` (which does interest me as it is a
Gentooism) ... i'll try to pick out only the relevant pieces as you said
yourself, the fcron things should go upstream.
> 2. is implmented by putting the following rules in /etc/crontab:
> 0 * * * * rm -f /var/spool/cron/lastrun/cron.hourly
> 1 3 * * * rm -f /var/spool/cron/lastrun/cron.daily
> 15 4 * * 6 rm -f /var/spool/cron/lastrun/cron.weekly
> 30 5 1 * * rm -f /var/spool/cron/lastrun/cron.monthly
> */10 * * * * /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons
> whose effect is, at intevals of one hour, day, week, and month, to
> remove some state files for the script run-crons, and also to run said
> script every ten minutes. The purpose of run-crons is to run the
> scripts in /etc/cron.{hourly,...} at the appropriate intervals, thus
> saving me the effort of adding a lot of lines looking like
> 1 3 * * * * some-command
> to my crontab.
you missed a critical aspect: offline time. the way run-crons is implemented,
if you happen to routinely shut your machine off at the time that the cronjob
is supposed to fire, then the standard you proposed will pretty much never
fire. the run-crons implementation however has a pretty good guarantee that
the periodic crons will get fired at the next uptime opportunity.
> Criticism:
> Both of these ideas are, in principle and in practice, inefficient and
> irritating.
> 1. Since I will only ever update my crontabs rarely, checking every
> ten minutes is likely to yield a negative result virtually 100% of the
> time; however, since one wants the system to respond quickly when a
> change is made, it is necessary to check frequently. This would seem
> to be a contradiction.
>
> 2. The problem is even worse: though it is conceivable that a real
> cron demon would be updating his crontabs willy-nilly, and thus that 1
> is not actually inefficient for him, it is not possible, even in
> principle, for 2 to be worthwhile. run-crons runs commands at
> intervals of no less than one hour, but is itself run every ten
> minutes.
these statements are incorrect as they are based on incorrect assumptions.
the point of the 10 minute cycle is not to see if anything of the cron dirs
have changed, but if any routine cronjob needs to fire (refer to my comment
above).
> Furthermore, the files /var/spool/cron/lastrun/cron.* are
> ALREADY handled in the run-crons script itself, so that most of the
> above commands would seem to be redundant.
this is most likely true.
> This one also has the
> additional unpleasant property of filling the logs with useless
> messages:
> [fcron] Job /usr/bin/test -x /usr/sbin/run-crons &&
> /usr/sbin/run-crons started for user
> systab
yes, this sucks, but so it goes.
> The reason that run-crons doesn't log is unclear to me.
there probably isnt one; file a bug with a patch if you like or just file a
bug.
-mike
signature.asc
Description: This is a digitally signed message part.
