race in cron

[Henry Spencer]

We saw an odd phenomenon with cron(8) the other day.  A while after we'd
taken some entries out of crontab, cron seemed to have forgotten about
some others.  The entries removed were at the end of crontab, and the
forgotten ones just preceded them.  We're not entirely certain why this
occurred, but one thin possibility occurred to us:  cron checks the
modification time on the file to decide whether re-reading is in order.
The mod time's resolution is one second.  Much can happen in one second.
Consider:

	1. Editor commences rewriting crontab.
	2. Kernel clock ticks one second.
	3. Cron stats crontab, decides re-read is in order.
	4. Cron finishes re-read, getting an incompletely-rewritten version.
	5. Editor finishes rewriting crontab.
	6. Crontab inode updated and time-stamped.
	7. Kernel clock ticks another second.

Cron has gotten a truncated crontab and has no way to realize this.  Does
anyone have any other suggestions as to possible causes?  The fix for this
one is to have cron check the size of the file to see whether it matches
the number of bytes in the last re-read.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry