CRON runs things twice (SUMMARY)

[Gerry Baumgartner]

Newsgroups: comp.bugs.sys5
Subject: Re: CRON runs things twice (SUMMARY)
Summary: 
Expires: 
References: <366 at trux.UUCP>
Sender: 
Followup-To: 
Distribution: 
Organization: Harris Computer Systems, Fort Lauderdale, FL
Keywords: cron

I'm getting into this discussion a little late, but I don't normally read this
group.  I was alerted to this discussion by someone who knew I worked on this
problem.

In article <366 at trux.UUCP> car at trux.UUCP (Chris Rende) writes:
>Thanks to all those who either posted or Emailed responses regarding
>the problem with CRON running things twice.
>
>The bottom line is that there is a bug in the AT&T System V CRON. It may
>have been fixed in more recent releases.
>
>The bug manifests itself by running something 1 second early and then AGAIN
>at the proper time.

I guess you could call it a bug in cron.  However, I kind of think of it as a
bug in the way the system keeps track of process that have called alarm, and
how it keeps time.   I believe that this problem would NOT occur on a system
that ran at 50HZ instead of 60HZ.

I worked on this problem a couple years ago, so the details may be a bit fuzzy.
Cron works one job at a time.  After he fires off one, he finds the next job to
be started, calculates the time difference between now and then, then calls
alarm.  This time is in seconds.

Every clock tick the system updates those processes who are in "alarm" mode by
updating their time-to-go by 1 tick.   This tick is an integer.   It is
calculated by taking 1,000,000 microseconds (1 sec) and dividing by HZ, 60 in
most cases.   This comes out to 15666.  The real answer is 15666.66666.....
This works out to the process alarm time being about 40usecs "faster" than the
system time for every 60 ticks.  

This causes the process to wakeup before it is "really" scheduled to, according
to the system time.   After cron starts it up, he checks his queue to see what
the next job he has to schedule is.  He looks at its time, looks at the system
time and says, "hey, this job starts in 1 sec" so it does an alarm(1) and
starts the job again 1 second later.

Working out the numbers, if you had one job on the schedule to run once every 7
hours or more, this problem would occur every time the job ran.  I don't recall
exactly if having other jobs on the schedule would affect the outcome, but I
believe they did.
>
>Here is a good summary and a fix from vogon.cetia.fr!philip:
>
>Most SV Rel. 2 systems share your problem.
>It seems to be that the (twisted) logic of cron takes the time
>several times during execution, and it is very lax in which one of
>the values obtained it actually believes.
>
>Rather than try to corect the logic, I have used a fix, which cures
>the problem, but has a side effect that *some* commands may be
>run one second late. I find this acceptable, since one second is within
>the normal scheduling tolerances of UNIX.
>
>I hope you have access to the sources, because here is a context
>diff showing my modificaton:
>
>*** cron.c	Thu Jan  4 12:26:40 1990
>--- cron.c.orig	Tue Mar  6 10:33:59 1990
>***************
>*** 239,245
>  #endif
>  		seconds = (ne_time < (long) 0) ? (long) 0 : ne_time;
>  		if(ne_time > (long) 0)
>! 			idle(seconds == 1L ? 2L : seconds);
>  		if(notexpired) {
>  			notexpired = 0;
>  			last_time = INFINITY;
>
>--- 239,245 -----
>  #endif
>  		seconds = (ne_time < (long) 0) ? (long) 0 : ne_time;
>  		if(ne_time > (long) 0)
>! 			idle(seconds);
>  		if(notexpired) {
>  			notexpired = 0;
>  			last_time = INFINITY;
>
>I suppose that on a really slow system, you may need to change the 2L
>into 3L - but that would be a *slow* machine.

My solution was a little different.  When cron got the alarm it would check the
current system time with what time he was supposed to be awakened.  If it was
more than 0 but less than 60 seconds away, he would sleep for that amount of
time, and start the job then.   

-------------------------------------------------------------------------------
Gerry Baumgartner                |    gerry at ssd.csd.harris.com 
System Software Development      | or gerry%ssd.csd.harris.com at eddie.mit.edu
Harris Computer Systems Division | or ...!{mit-eddie,uunet,novavax}!hcx1!gerry
Fort Lauderdale FL 33309         |
-------------------------------------------------------------------------------