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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
