fix to crontab problem ("no changes made to crontab")

fix to crontab problem ("no changes made to crontab")

Post by Jim Cochra » Mon, 15 Jul 2002 12:12:40

I just encountered a very irritating problem with crontab on redhat 7.3
(which may apply to other newer distributions).  After searching a while
on google and finding very few hits, I managed to find an explanation of
what was going wrong.  I was surprised to find so few hits for this
problem, since it seems to be one that a lot of people would have

I thought I'd post the solution here in case others are having this
problem.  The URL that describes what is going on is:

I'll copy the text from that post below in case it expires.

The fix I came up with - and there may be a cleaner fix, others are
welcome to make suggestions - is, since crontab on my system is in
/usr/bin, I created a a bash script as /bin/crontab:


EDITOR=/usr/bin/elvis /usr/bin/crontab $*

One needs to make sure /usr/bin/elvis exists, of course.

Here's the post explaining what is going on.

Re: crontab -e scuppered by non-updated mtime. fstat64() lied!

Date: Sat Oct 27 2001 - 14:15:47 EEST

    * Next message: Igor Mozetic: "Re: Any stable 2.4 kernel?"
    * Previous message: Florian Schmitt: "Re: crypto api and 2.4.13"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [
* attachment ]

This message is to thank Dr. Horst H. von Brand and to act as an

Over 2 month ago I questioned fstat64() and whether st_mtime was being
updated correctly after using crontab -e reported no changes made.
Dr. Horst H. von Brand sent me the following explanation:

Quote:> Some editors (e.g. emacs, vi) go to lengths to ensure the "new" file
> is the same inode as the "old" one. Others (jed) don't. Has screwed me
> more than once...

This was exactly the problem I was having. I had all the evidence I
needed but I couldn't see it. The details were as follows:
  1) Crontab -e command created a temporary file called
      /tmp/crontab.812, and with the open file handle called fstat64()
      to get the mtime.
  2) Crontab ran Vim on the temporary file and I edited the file and
      saved it.
      Unknown to me Vim (6.0z BETA) had replaced the /tmp/crontab.812
      file with a new one of the same name. The stat /tmp/crontab.812
      commands I ran did show that the inode had changed but I didn't
      notice it.
  3) Crontab then called fstat64() on its original open file handle
      to the now deleted file. Since Vim did not edit this file its
      mtime had not changed, hence crontab reported no changes made.
      (When a file is deleted the directory entry is removed and
      the inode link count is reduced by 1. When the link count
      reaches 0 the file is removed, but not before all open file
      handles are closed).


> Hello all,

> I have found an unexpected behaviour of fstat64() I hope someone here
> can explain. I used crontab -e but after making a change I got the
> following error:
> crontab: no changes made to crontab.

> The crontab process calls fstat() just before handing a temporary file
> to your favourite editor and just after. It compares the st_mtime
> value to see it you made a change and updates your crontab if required.
> The problem is I did make a change but crontab didn't see one. I did
> the following:

> strace -v crontab -e 2> /tmp/crontab.strace
> ^Z (Suspended Vim)
> stat /tmp/crontab.812
> fg
> (Made a change and wrote the file)
> ^Z
> stat /tmp/crontab.812 (mtime had been updated)
> fg
> (Quit Vim)
> crontab: no changes made to crontab.

> The strace file showed that fstat64() returned exactly the same data
> before and after, seeing no change!

> fstat64() now becomes inconsistent, if I change my editor to the
> following shell script (/tmp/edit):

> sleep 2
> echo "# edit $$ was here!" >> "$1"

> and run it with:

> EDITOR=/tmp/edit strace -v crontab -e 2> /tmp/crontab.strace-2

> everything works as expected. The strace file showed that fstat64()
> reported different mtimes and crontab did its job as expected.

> I got the same results with kernel 2.4.8 and RedHat patched 2.4.3-12.
> All file-systems are ext2.

> Can anybody else reproduce this behaviour?
> It something broken?

> Mike

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at
Please read the FAQ at

    * Next message: Igor Mozetic: "Re: Any stable 2.4 kernel?"
    * Previous message: Florian Schmitt: "Re: crypto api and 2.4.13"
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [
* attachment ]

This archive was generated by hypermail 2.1.0 : Sun Oct 28 2001 - 23:53:08
Jim Cochrane

[When responding by email, include the term non-spam in the subject line to
get through my spam filter.]


1. Type "(", ")" and "{", "}" in X...


When i start a shell under X, i can type all characters on my keyboard,
the same when i start the simple editor, but when i start Forte (Java
IDE) written in Java i cant use the "(", ")", "{", "}" and allmost none
of the characters that are located on the same key as a number...

Does anybody have an idea what i can do about that... could it be
something with programs written in Java..?


Sent via
Before you buy.

2. buried ethernet cable

3. link a crontab -> "crontab -e" remove link

4. UNIX "learn" or similar utility?

5. Are changes made with "route" and "ifconfig" permanent?

6. 2 questions please read

7. GETSERVBYNAME()????????????????????"""""""""""""

8. where are my files

9. fix for problems installing from local HD ("unable to intial console")

10. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

11. Using "if" in "ksh" to change "for loop" values....

12. SUMMARY: "find" in root crontab hangs Solaris 2.2

13. where can I ftp "metaconfig" (generator of "Configure")?