Date: Wed, 1 Feb 2012 07:42:11 -0500 From: John Baldwin <jhb@freebsd.org> To: Doug Barton <dougb@freebsd.org> Cc: current@freebsd.org Subject: Re: Race between cron and crontab Message-ID: <201202010742.11936.jhb@freebsd.org> In-Reply-To: <4F28A210.90303@FreeBSD.org> References: <201201311149.32760.jhb@freebsd.org> <4F28A210.90303@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202010742.11936.jhb>