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