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

3 wyświetlenia
Przejdź do pierwszej nieodczytanej wiadomości

Jim Cochrane

nieprzeczytany,
13 lip 2002, 23:12:4013.07.2002
do

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
encountered.

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

http://hypermail.idiosynkrasia.net/linux-kernel/archived/2001/week43/1349.html

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:

#!/bin/bash

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!
From: Mike Fleetwood (mi...@rockover.demon.co.uk)
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
explanation:

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:
> 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).

Thanks,
Mike

On Wed, 15 Aug 2001, Mike Fleetwood wrote:

> 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
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

* 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
EET
--
Jim Cochrane
j...@dimensional.com

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

Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż dalej
Nowe wiadomości: 0