From dillon@flea.best.net  Mon Jan 26 10:42:43 1998
Received: from flea.best.net (root@flea.best.net [206.184.139.131])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03299
          for <FreeBSD-gnats-submit@freebsd.org>; Mon, 26 Jan 1998 10:42:43 -0800 (PST)
          (envelope-from dillon@flea.best.net)
Received: (from dillon@localhost) by flea.best.net (8.8.8/8.7.3) id KAA10811; Mon, 26 Jan 1998 10:41:27 -0800 (PST)
Message-Id: <199801261841.KAA10811@flea.best.net>
Date: Mon, 26 Jan 1998 10:41:27 -0800 (PST)
From: Matt Dillon <dillon@best.net>
Reply-To: dillon@best.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: major time step blows cron up
X-Send-Pr-Version: 3.2

>Number:         5572
>Category:       bin
>Synopsis:       A major time step blows cron up, runs thousands of processes
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 26 10:50:00 PST 1998
>Closed-Date:    Sat Dec 12 22:08:01 PST 1998
>Last-Modified:  Sat Dec 12 22:08:40 PST 1998
>Originator:     Matt Dillon
>Release:        FreeBSD 2.2.5-STABLE i386
>Organization:
Best Internet Communications
>Environment:

	Loaded shell machines with lots of accounts and lots of cron
	jobs.

>Description:

	If a major time step occurs, for example a backwards time step,
	cron will attempt to run every single job in between.  This
	can result in cron starting thousands of jobs for the last N
	hours or N days, depending on how large a time step occured.

>How-To-Repeat:

	Create some cron jobs and set the time backwards by a few hours.

>Fix:

	The fix is included below.  We check for nonsensical time steps
	and deal with them by resynchronizing cron's internal time
	tracking.
	
*** LINK/cron.c	Wed Sep 17 15:10:45 1997
--- cron.c	Mon Jan 26 10:36:26 1998
***************
*** 229,234 ****
--- 229,248 ----
  cron_sleep() {
  	register int	seconds_to_wait;
  
+ 	/*
+ 	 * Look for time step and don't run all the friggin cron jobs in
+ 	 * between if a major backwards step occurs.  Otherwise, a major 
+ 	 * time step (e.g. if the time gets messed up on the machine) may 
+ 	 * cause thousands of cron jobs to be run, especially if you have a lot
+ 	 * of users.
+ 	 */
+ 
+ 	seconds_to_wait = (int) (TargetTime - time((time_t*)0));
+ 
+ 	if (seconds_to_wait < -600 || seconds_to_wait > 600) {
+ 	    cron_sync();
+ 	}
+ 
  	do {
  		seconds_to_wait = (int) (TargetTime - time((time_t*)0));
  		Debug(DSCH, ("[%d] TargetTime=%ld, sec-to-wait=%d\n",


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: dillon 
State-Changed-When: Sat Dec 12 22:08:01 PST 1998 
State-Changed-Why:  
Sheesh.  Nobody fixed this one?  crunch crunch crunch 
>Unformatted:
