Re: Race between cron and crontab

On Tuesday, January 31, 2012 9:23:12 pm Doug Barton wrote:
> 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

I don't want it to have sub-second granularity, I just want to make
'crontab -e' more reliable so that cron doesn't miss edits.  cron is
currently using the mod-time of the spool directory as the 'something
changed' flag (have you read the cron code?).  The problem is that it
currently can set the 'something changed' flag non-atomically while it is
updating a crontab.

-- 
John Baldwin