Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.bugs.v7,net.unix-wizards Subject: race in cron Message-ID: <4497@utzoo.UUCP> Date: Thu, 18-Oct-84 16:58:58 EDT Article-I.D.: utzoo.4497 Posted: Thu Oct 18 16:58:58 1984 Date-Received: Thu, 18-Oct-84 16:58:58 EDT Organization: U of Toronto Zoology Lines: 24 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