Do you remember what the error (from errno) usually was?  I changed cron
a bit to catch the error, and also to prevent it from exiting.  I also
feel that just repeating the stat would work, so I made cron pretend that
nothing has changed (in the spool dir) if the stat fails.  A patch is at
the end of this message (I sent it to Paul and Christos for review, too).

+ Kim


| From:    Robert Elz <kre@munnari.OZ.AU>
| Date:    Tue, 08 Aug 2000 10:21:45 +1000
|
| I spent a bunch of time attempting to figure out what is going on, and got
| nowhere at all, on one system that this this I had cron dumping all kinds of
| status (errno values, current working directory, the buffer containing the
| name it was performing the stat() of) and never saw anything at all that
| could explain the problem.   That is, I convinced myself that this has to
| be a kernel problem of some kind.

Index: database.c
===================================================================
RCS file: /cvsroot/basesrc/usr.sbin/cron/database.c,v
retrieving revision 1.4
diff -u -r1.4 database.c
--- database.c	1998/01/31 14:40:26	1.4
+++ database.c	2000/08/07 22:58:57
@@ -32,6 +32,7 @@
 
 #include "cron.h"
 #include <fcntl.h>
+#include <errno.h>
 #include <sys/stat.h>
 #include <sys/file.h>
 
@@ -62,8 +63,9 @@
 	 * cached any of the database), we'll see the changes next time.
 	 */
 	if (stat(SPOOL_DIR, &statbuf) < OK) {
-		log_it("CRON", getpid(), "STAT FAILED", SPOOL_DIR);
-		(void) exit(ERROR_EXIT);
+		statbuf.st_mtime = 0;
+		log_it("CRON", getpid(), "SPOOL DIR STAT FAILED",
+		       strerror(errno));
 	}
 
 	/* track system crontab file
@@ -78,7 +80,7 @@
 	 * so is guaranteed to be different than the stat() mtime the first
 	 * time this function is called.
 	 */
-	if (old_db->mtime == TMAX(statbuf.st_mtime, syscron_stat.st_mtime)) {
+	if (old_db->mtime >= TMAX(statbuf.st_mtime, syscron_stat.st_mtime)) {
 		Debug(DLOAD, ("[%d] spool dir mtime unch, no load needed.\n",
 			      getpid()))
 		return;