Red Hat Bugzilla – Bug 149561
crontab -e fails to notice change in tmp file if edit is under 1 second
Last modified: 2007-11-30 17:07:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Description of problem:
If the temporary crontab file provided by crontab -e for the editor is
edited in under 1 second, the edit is not noticed, and not loaded.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.create a script that accepts a filename as argument, and adds valid
crontab lines (eg: * * * * * /bin/echo "something") to that file.
2.set that script to be the editor for crontab -e by doing: export
3.run crontab -e
Actual Results: the temp file gets modified in under 1 second, so the
modtime of the tempfile that crontab -e created is not updated.
Crontab checks the modtime and finds no change, so it doesn't load the
(modtime being the value of st_mtime in the stat struct)
Expected Results: This change should be detected, regardless of how
fast it the editor edits the script.
Perhaps if it checked st_size and st_mtime instead of just st_mtime.
Since st_mtime is in seconds, any edit that takes less than one second
is not visible to crontab -e.
A simple work around for scripts that act as editors for crontab is to
make them sleep for a couple seconds before writing to the file, so
that st_mtime can be updated.
An even simpler workaround is just to use stdin, ie.:
$ myscript | crontab
would replace the current user's crontab with the output of 'myscript'.
The 'crontab -e' mode exists to enable crontab editing by human users.
No human users could ever complete an edit in less than a second ,
(if you can prove otherwise, please feel free to do so!:) and we
already provide a way for non-human users to replace crontabs - see
above. Hence, this bug is being closed as "not a bug" .
However, I will look at using the 64-bit time in stat->st_mtim.tv_usec
in future releases (st_mtime is #define'd to st_mtim.seconds on 2.4+