I keep getting messages about find: /var/spool/cron/lastrun/cron.hourly: No such file or directory So I checked /usr/sbin/run-crons and found some problems. I fixed them like this: 1. Inefficient to use TIME="-cmin +60 -o -cmin 60" ;; # this means > 60 || == 60 (>= 60) use TIME="-cmin +59" ;; # this means > 59 (which means >= 60) and such constructs instead. (Very minor) 2. use of xargs. use find properly: find /var/spool/cron/lastrun/$BASE $TIME -exec /bin/rm {} \; instead of xargs. Result? Cleaner and more efficient, and no more annoying emails!
hey there - thats a good one, thanks. i submitted a new run-crons to cvs, please test. simply remerge cronbase for that. i'll make a new ebuild as soon as you confirm, that it is working on your machine also - that way everybody will enjoy your improvements. thanks for the QA regards Thilo
I'll hop right on that. I'm still experiencing some minor issues, and will test your version ASAP. If that doesn't fix it, I'll keep at it until it's fixed! Thanks.
Created attachment 1669 [details, diff] a patch to run-crons
I've added a diff as an attachment. Please look it over and tell me what you think!
*** Bug 3984 has been marked as a duplicate of this bug. ***
The more I analyze this problem the more I think there is a race condition! Consider: 'root' is directed to run "crontab /etc/crontab" which replaces root's crontab entry with the one in /etc/crontab (for dcron, anyway). Now also consider that this same crontab executes the /usr/sbin/run-crons command every 15 minutes, and additionally removes the /var/spool/cron/lastrun/cron.{hourly,daily,weekly,monthly} files on their scheduled times (hourly, daily, etc...) Now finally consider that the /usr/sbin/run-crons program is supposed to do several things: 1. IF the /var/spool/cron/lastrun/cron.whatever file is older than necessary (> 1 hour for hourly, etc...), it is removed. (This *seems* to be duplicate removal via root's crontab and the run-crons program == a race.) 2. Then, if a lastrun file for the specified time interval doesn't exist, create it and run the jobs that would be associated with that time interval. I think that step 1 is unnecessary in the face of the /etc/crontab (or root's crontab) setup, *or*, that some entries in /etc/crontab (root's crontab) need to be taken *out*, leaving just the run-crons job. The jobs in the crontab file (/etc == roots) are explicit about *when* the jobs run. Thus, I feel they should be 'canonical', and the run-crons program should never remove touch files.
Created attachment 1703 [details] run-crons This is the run-crons that I'm using now. So far so good. One *could* put the 'remove cron.foo if it is older than <foo> units old' back in, but I would suggest that it's not necessary (or warranted) if the *other* cron jobs are running.
looks good - i agree that the deletion of run-crons touch files only be handled one place and that the "system" crontab is more intuitive for this... i'll test it a little and on completion make a new cronbase release. now if only this would help me on my programming exam tomorrow ;)
After a weekend off, I've just caught up with this. Sorry I started a new report (3984) - I didn't search on the right words. I think that it is important to leave the removal of touch files in *both* of the places where they are now. Here's my reasoning: The rm lines in crontab ensure that the jobs run at the pre-defined interval at the defined time/day, i.e. normal operation. The removal of "too old" files in run-crons makes sure that you don't miss a scheduled run if the box is down at the relevant time. Or to put it another way, when you bring up a box you get to run hourly, daily, weekly *and*4 monthly jobs within 15 minutes of booting if they are overdue. Of course you may not agree that this should happen but I've found it to be very useful. Also to add my "test" data: I've had 2 1/2 boxes running over the weekend with no spurious emails, so I still suggest delaying run-crons by 1 minute. The test/find changes suggested by Jon look good to me as well. Regards, George.
I can accept your reasoning -- I don't like simply delaying one minute, because that assumes it takes < 1 minute to remove the touch files (which except on a heavily loaded, slow system would be true), but I'm otherwise OK with it. Perhaps 5 minutes? More than enough time, yes? george - what browser did you use when you submitted this last bug reported -- it appears to be broken and doesn't wrap lines. Grr! Also, could you attach your *current* run-crons and either I or Thilo will merge them - I would like to try it out if possible.
Created attachment 1745 [details] my latest run-crons THis run-crons file automatically removes lastrun files that are 5 minutes or more older than their specified interval. (1 hour == 65 minutes, 1 day == 24h + 5 minutes, etc...)
Non-wrapping browser was Konqueror 3.0.1. I'll try Galeon (1.2.5) this time... run-crons is unchanged out of cronbase 0.01 but I'll attach it anyway. Can't attach it (too busy to look at this now) so here it is... ----------------------------------------------------------------- #!/bin/sh # # /space/gentoo/cvsroot/gentoo-x86/sys-apps/cronbase/files/run-crons,v 1.3 2002/05/13 18:34:05 bangert Exp # # 20 Apr 2002; Thilo Bangert <bangert@gentoo.org> run-crons: # # moved lastrun directory to /var/spool/cron/lastrun # # # Author: Achim Gottinger <achim@gentoo.org> # # Mostly copied from SuSE # # this script looks into /etc/cron.[hourly|daily|weekly|monthly] # for scripts to be executed. The info about last run is stored in # /var/spool/cron/lastrun mkdir -p /var/spool/cron/lastrun # for CRONDIR in /etc/cron.{hourly,daily,weekly,monthly} do test -d $CRONDIR || continue BASE=${CRONDIR##*/} test -e /var/spool/cron/lastrun/$BASE && { case $BASE in cron.hourly) TIME="-cmin +60 -or -cmin 60" ;; cron.daily) TIME="-ctime +1 -or -ctime 1" ;; cron.weekly) TIME="-ctime +7 -or -ctime 7" ;; cron.monthly) TIME="-ctime +30 -or -ctime 30" ;; esac eval find /var/spool/cron/lastrun/$BASE $TIME | \ xargs --no-run-if-empty rm } if test ! -e /var/spool/cron/lastrun/$BASE ; then touch /var/spool/cron/lastrun/$BASE set +e for SCRIPT in $CRONDIR/* do test -d $SCRIPT && continue if test -x $SCRIPT ; then $SCRIPT fi done fi done # touch /var/spool/cron/lastrun find /var/spool/cron/lastrun -newer /var/spool/cron/lastrun | \ xargs --no-run-if-empty rm ----------------------------------------------------------------- As for the delay, any number is fine by me. Obviously <15 as it runs every 15 minutes. (sorry about stating the obvious, but it's a habit). George.
Chasing down my bugzilla probs, I've just found bug #3199. I'm not in a position to try without a proxy but it all reads just like I'm seeing, the bit that's relevant here is the no-wrap with Konqueror. George.
The last attachment I sent in ("my latest run-crons") seems to be working perfectly. I feel comfortable recommending it, now.
alright - this looks good and is working as expected on my machine as well. we might just reach the end here. thanks for your testing and your recommendations.... run-crons is in cvs now and i'll probably commit a new cronbase tomorrow. if you are interested in more run-crons hassel i suggest you take a look at bug #3269 about: "Inconvenient defaults for /etc/cron.[daily|weekly|monthly] in /etc/crontab". http://bugs.gentoo.org/show_bug.cgi?id=3296 regards Thilo
