cs374107@umbc5.umbc.edu (02/02/90)
At my home system, cron is acting weird (SCO 386 Xenix), cron seems to be activating once,ie my 'news' file in crontabs does not get executed but the first time I boot. Any ideas as how to fix this? Thanks cs374107@umbc5.umbc.edu preferably send mail to: uunet!ocsmd!stsim!glenn
kabra437@pallas.UUCP (Ken Abrams) (02/03/90)
In article <2735@umbc3.UMBC.EDU> cs374107@umbc5.umbc.edu () writes: > >At my home system, cron is acting weird (SCO 386 Xenix), cron seems to be >activating once,ie my 'news' file in crontabs does not get executed but >the first time I boot. Any ideas as how to fix this? Thanks Put the following in your crontabs: 1 * * * * /bin/true This will keep cron "awake". There is a known problem with cron going to sleep with Xenix '386. This should fix it. Supplied by SCO Tech. Support. Works for me. -- ======================================================== Ken Abrams uunet!pallas!kabra437 Illinois Bell kabra437@athenanet.com Springfield (voice) 217-753-7965
soup@penrij.LS.COM (John Campbell) (02/04/90)
In article <269@pallas.UUCP>, kabra437@pallas.UUCP (Ken Abrams) writes: > In article <2735@umbc3.UMBC.EDU> cs374107@umbc5.umbc.edu () writes: > > > >At my home system, cron is acting weird (SCO 386 Xenix), cron seems to be > >activating once,ie my 'news' file in crontabs does not get executed but > >the first time I boot. Any ideas as how to fix this? Thanks > > Put the following in your crontabs: > 1 * * * * /bin/true > This will keep cron "awake". There is also another possibility, one which I tripped over (rather uncomfortably). For the longest time I liked using the /usr directory for users on the system, but I didn't want them in the root partition. Odd, yes, but I was young and still pretty thick (still am, come to think of it)... So I created another partition (XENIX 2.2+) and placed the /usr ptn out there, keeping a minimal copy on the root partions so I could boot. This trick worked fine until SCO coughed up 2.3. Under 2.3, cron got started before the usr file system got mounted! This truly messed things up for me- I was used to midnight polls at home and was no longer getting them. Well, after 2 weeks (couldn't spend full time checking) I finally realized (after pulling Sys V.3 source and replacing cron!) what my problem was. I adjusted the sequence in /etc/rc.d to ensure that /etc/cron started AFTER the file systems were mounted. Please don't laugh- Like Intel and MicroSoft, SCO keeps breaking things. Of course, for SCO, a lot of this stuff _worked_ at one time. After all, neither Intel nor MicroSoft have something working to avoid fixing. (If it ain't broke, don't fix it). Otherwise not entirely displeased with SCO. -- John R. Campbell ...!uunet!lgnp1!penrij!soup (soup@penrij.LS.COM) "In /dev/null no one can hear you scream"
mark.levy@canremote.uucp (MARK LEVY) (02/09/90)
cu>Orga: University of Maryland, Baltimore County cu>At my home system, cron is acting weird (SCO 386 Xenix), cron seems cu>to be activating once,ie my 'news' file in crontabs does not get cu>executed but the first time I boot. Any ideas as how to fix this? cu>Thanks I seem to recall hearing about this. I believe that what you need to do is to periodicly execute something. If cron goes to sleep for more than an hour or so, I believe that it won't wake up. Mark --- ~ DeLuxe 1.11a18 #3019 ~ QNet 2.04a:NorthAmeriNet: Sound Advice BBS ~ Gladstone ~ MO
pmartin@psmsd.UUCP (Paul Martin) (02/10/90)
In article <269@pallas.UUCP>, kabra437@pallas.UUCP (Ken Abrams) writes: > In article <2735@umbc3.UMBC.EDU> cs374107@umbc5.umbc.edu () writes: > > > >At my home system, cron is acting weird (SCO 386 Xenix), cron seems to be > >activating once,ie my 'news' file in crontabs does not get executed but > >the first time I boot. Any ideas as how to fix this? Thanks > > Put the following in your crontabs: > 1 * * * * /bin/true > This will keep cron "awake". > There is a known problem with cron going to sleep with Xenix '386. > This should fix it. Supplied by SCO Tech. Support. Works for me. What version of Xenix/386 is cron broke? Is the problem only with cron files other than root in crontabs dir? I am running Xenix/386 2.3.2 and have not noticed this problem but I bring my machine up and down all the time. But the roon cron file entries are being executed just fine. Am I missing something about the problem? Just worried (hopefully for nothing)! -- +--------[ Paul Martin at P.S.M. Software Development ]--------+ | Smart: pmartin@psmsd.UUCP | "Yes I am serious, and don't | | Dumb: ...uccba!psmsd!pmartin | call me Shirley!" | +-------------------------------+------------------------------+
srodawa@egrunix.UUCP (Ronald Srodawa) (02/10/90)
My Xenix 2.3.2 on a '386 has been running most recently for 15 days and cron stays just fine.
aryeh@eddie.mit.edu (Aryeh M. Weiss) (02/11/90)
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). Like others, I found this out the hard way: I tried sending a SIGALRM to cron, and it woke up executed the next job it has on the queue. The answer hit me like a diamond bullet through my brain. Most people have something running every hour, like uudemon.hr, so this problem is rarely seen. --
brad@microm.UUCP (Bradley W. Fisher) (02/12/90)
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` #<EOF> ... 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
aryeh@eddie.mit.edu (Aryeh M. Weiss) (02/12/90)
In article <252@microm.UUCP> brad@microm.UUCP (Bradley W. Fisher) writes: >In article <1990Feb10.193851.16968@eddie.mit.edu>, aryeh@eddie.mit.edu (Aryeh M. Weiss) writes: ... my own ravings deleted ... > >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 ... > ... ># 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 ... This subclause is just to check that /dev/clock exists and is readable. If the cat fails then the exit is taken. Otherwise setclock is executed. (Remember that commands that fail and return non-zero exit status are considered to be FALSE conditions; commands that return zero are TRUE.) This effectively suppresses an error message from cron being mailed to root. If it was written as cat -s /dev/clock && /etc/setclock `...` then if cat -s failed then cron would see an over all non-zero exit status. You don't make something clear: was "cat -s ..." command the only thing in your crontab before you changed it? If so you may have been another victim of the cron 24-hour bug. The "cat -s" command is in there because the interrupt clocks on various systems do not run the same, but the RTC is assumed to be perfect (obviously untrue). I also adjust the RTC to agree with the software clock once per day, but my RTC runs pretty well. You have a problem but there is nothing wrong with sync'ing your RTC. On the other hand, I don't like it when the software clock is changed by cron. It just rubs me the wrong way .. what if you had some kind of experimental monitoring system that required accurate time keeping and whump! the clock suddenly gets bumped in the middle of the night? My interrupt clock was running fast causing my system to gain a few minutes a day, so I carefully adjusted the clknumb variable in the kernal. Now the system is off at most a half minute per month. --