henry@utzoo.UUCP (Henry Spencer) (10/18/84)
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!henrymatt@ucla-cs.UUCP (10/24/84)
#endif lineeater
One could `touch' the new copy of crontab, to force cron to re-read the
crontab. Or one could edit a scratch copy of crontab (in the same
filesystem), then `mv scratch /usr/lib/crontab', which will prevent
this race from occuring (since only links and unlinks are involved in
the `mv').
A different fix than the one suggested would be to sleep for a few seconds
after detecting the changed crontab. This would give the editor time to
write the file (except on floppy-based systems :-) ), and is even simpler
than a stat.
- Matt
(Dept. of Old Crons)
-------
UUCP: {ucbvax,ihnp4,randvax,trwrb!trwspp,ism780}!ucla-cs!matt
ARPA: matt@ucla-locus