Race between cron and crontab
jhb at freebsd.org
Wed Feb 1 21:26:49 UTC 2012
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.
More information about the freebsd-current