Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!asuvax!hrc!microm!brad From: brad@microm.UUCP (Bradley W. Fisher) Newsgroups: comp.unix.xenix Subject: Re: cron Summary: cron Message-ID: <252@microm.UUCP> Date: 11 Feb 90 21:06:49 GMT References: <2735@umbc3.UMBC.EDU> <269@pallas.UUCP> <22@psmsd.UUCP> <1990Feb10.193851.16968@eddie.mit.edu> Organization: Micro Maintenance, INC., Tempe, AZ Lines: 47 In article <1990Feb10.193851.16968@eddie.mit.edu>, aryeh@eddie.mit.edu (Aryeh M. Weiss) writes: > The problem stems from the fact that cron is a 8086 program. The way cron > works is that it computes how long it has until the next job and executes > sleep. Unfortunately in the 8086 world the sleep argument is a 16-bit int, > which is inadequate if you only have one cron job a day! (24 hours = 86400 > seconds) The fix is to run a job every hour, like date, and redirect output > to /dev/null (or wherever you like). I agree with your belief that cron must be nudged every once in a while ... my situation was a little different, so I thought I'd through it up here for all to muse ... I've got two identical 386 AT clones running 2.3.1, and cron works just fine on one and not on the other. The one that doesn't work though DOES have a problem with the CMOS clock running way too fast! Gains about 10 minutes an hour. My fix (all does seem to work fine now) was to write a short script file to update the CMOS clock with the "real time" (kernel's) clock. This works because both cpu's run 24 hrs a day, and once set, the real time clock doesn't change and is pretty accurate. Here's the top part of my crontab ... #------------------------------------------------------------------------------ #Min Hour Day Month Day Command #of of of of of #Hour Day Month Year Week #0-59 0-23 1-31 1-12 0-6(0=Sunday) #------------------------------------------------------------------------------ # I'm taking out the next line temporarily, 'cause cron won't run #1 2 * * * cat -s /dev/clock >/dev/null 2>&1 || exit 0;/etc/setclock `date +\%m\%d\%H\%M\%y` 58 * * * * /usr/lib/news/fixclock #fix cmos clock ... and here's what I put in "fixclock" ... # "fixclock" ... takes output from the "date" command and sets the CMOS clock. /etc/setclock `date +\%m\%d\%H\%M\%y` # ... now obviously this idea was taken from the remarked line in crontab. Which brings up another question ... does that line (the remarked one, which came from the orginal crontab unremarked) make sense? I read it to mean that if the first command retruns a non-zero exit status(cat -s /dev/clock) then the second command(exit 0) will be executed. When would "cat -s /dev/clock" exit with any status other than "0", even if the date is wrong? And even if it did, "exit 0" would dump you right out, so when would the last command(/etc/setclock ....) ever be executed? Seems wrong to me so that's why I made "fixclock" and run it once every hour. I'm just a wanna be UNIX guru (IJWBUG) | Micro Maintenance, Inc. | 2465 W. 12th St. #6 -== Brad Fisher ==- | Tempe, Arizona 85281 ...!asuvax!mcdphx!hrc!microm | 602/894-5526