Re: Race between cron and crontab

On 01/31/2012 08:49, John Baldwin wrote:
> A co-worker ran into a race between updating a cron tab via crontab(8) and 
> cron(8) yesterday.  Specifically, cron(8) failed to notice that a crontab was 
> updated.  The problem is that 1) by default our filesystems only use second 
> granularity for timestamps and 2) cron only caches the seconds portion of a 
> file's timestamp when checking for changes anyway.  This means that cron can 
> miss updates to a spool directory if multiple updates to the directory are 
> performed within a single second and cron wakes up to scan the spool directory 
> within the same second and scans it before all of the updates are complete.
> 
> Specifically, when replacing a crontab, crontab(8) first creates a temporary 
> file in /var/cron/tabs and then uses a rename to install it followed by 
> touching the spool directory to update its modification time.  However, the 
> creation of the temporary file already changes the modification time of the 
> directory, and cron may "miss" the rename if it scans the directory in between 
> the creation of the temporary file and the rename.
> 
> The "fix" I am planning to use locally is to simply force crontab(8) to sleep 
> for a second before it touches the spool directory, thus ensuring that it the 
> touch of the spool directory will use a later modification time than the 
> creation of the temporary file.

If you really want cron to have sub-second granularity I don't see how
you could do it without using flags.

crontab open	sets flag that it is editing a file
crontab close	clears "editing" flag, sets "something changed" flag
		(if something actually changed of course)

cron	checks existence of "something changed" flag, pulls the
	update if there is no "editing" flag, clears "changed" flag


Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/