Path: utzoo!attcan!uunet!snorkelwacker!mit-eddie!aryeh
From: aryeh@eddie.mit.edu (Aryeh M. Weiss)
Newsgroups: comp.unix.xenix
Subject: Re: cron
Message-ID: <1990Feb12.145915.17427@eddie.mit.edu>
Date: 12 Feb 90 14:59:15 GMT
References: <2735@umbc3.UMBC.EDU> <269@pallas.UUCP> <22@psmsd.UUCP> <1990Feb10.193851.16968@eddie.mit.edu> <252@microm.UUCP>
Reply-To: aryeh@eddie.MIT.EDU (Aryeh M. Weiss)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 43

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.
--