Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucla-cs.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrba!cepu!ucla-cs!matt
From: matt@ucla-cs.UUCP
Newsgroups: net.bugs.v7,net.unix-wizards
Subject: Re: race in cron
Message-ID: <1798@ucla-cs.ARPA>
Date: Tue, 23-Oct-84 21:28:52 EDT
Article-I.D.: ucla-cs.1798
Posted: Tue Oct 23 21:28:52 1984
Date-Received: Fri, 26-Oct-84 09:08:29 EDT
References: <4497@utzoo.UUCP>
Organization: UCLA CS Dept.
Lines: 18
Xref: 87 10085

#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