Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [SLE] cron not recognizing changes to /etc/cron.d files [SOLVED]
  • From: Richard Bos <radoeka@xxxxxxxxx>
  • Date: Wed, 12 Apr 2006 20:48:28 +0200
  • Message-id: <200604122048.30930.radoeka@xxxxxxxxx>
Op woensdag 12 april 2006 14:49, schreef Joachim Schrod:
> Richard Bos wrote:
> > Have a look here:
> > http://susewiki.org/index.php?title=Schedule_cron_daily
>
> Please don't take this email as a personal critic. Since you wrote most of
> this page, I thought you might be interested in feedback and proposals for
> improvement of this page.

Thanks for the feedback. Please, put it in the wiki, that is what a wiki is
for! Your information will make the page more valuable for others. No
without your update, it remains the same...

> The warning after the tip to change the system time should be more
> explicit, IMNSHO. It is *never* a good idea to change system time just to
> create a file accordingly. Too many other services need continuous time.
> IMHO this should be marked as a "bad proposal" that might pop up and is
> listed on the page just to warn against it.
>
> I think that the stat example is better understandable if the stat command
> is without the -c option. Just calling stat outputs these times at the end;
> that's as easy to grasp for the user and easier to write. You might also
> want to include an example output on the page.
>
> To use find to output the ctime is rather obscure. IMO the ls command with
> option -lc is more appropriate, and this obvious solution (most people use
> ls to show meta-information of files) is missing on the page.
>
> It's not only said that the touch command does not work; that is
> definitively the case. There is no need to check. There ain't no POSIX or
> Linux function to set ctime; it's as simple as that. (My question about
> about another way, in a post some days ago, was rhetoric. I'm programming
> in UNIX for 25 years now, and my experience tells me: that's the way it is,
> sadly.)
>
> Your "Another Solution" section on the Wiki page is misleading. touch
> *always* updates ctime to the current timestamp, there is no way to avoid
> that. The sentence on the Wiki "touch -t only modifies acces-time and
> modify-time." reads as if this command would not change ctime, but it does.

Check the 'history' of the page and you'll see, that someone else than me
added that to the page.

> To wit:
> puma:tmp $ touch testfile
> puma:tmp $ stat testfile
> File: `testfile'
> Size: 0 Blocks: 0 IO Block: 8192 regular
> empty file Device: 17h/23d Inode: 623423 Links: 1
> Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc)
> Access: 2006-04-12 14:16:39.791001499 +0200
> Modify: 2006-04-12 14:16:39.791001499 +0200
> Change: 2006-04-12 14:16:39.791001499 +0200
> puma:tmp $ touch -t 04110000 testfile
> puma:tmp $ stat testfile
> File: `testfile'
> Size: 0 Blocks: 0 IO Block: 8192 regular
> empty file Device: 17h/23d Inode: 623423 Links: 1
> Access: (0664/-rw-rw-r--) Uid: ( 1014/ schrod) Gid: ( 2000/ npc)
> Access: 2006-04-11 00:00:00.000000000 +0200
> Modify: 2006-04-11 00:00:00.000000000 +0200
> Change: 2006-04-12 14:17:11.612405346 +0200
>
> See how the touch not only set atime and mtime, but also updated ctime to
> the current timestamp.
>
> That is not an issue with touch. The reason is the underlying POSIX
> function utime() (or utimes(), alternatively) that does that ctime update
> unconditionally; there's no way to avoid that. See
> http://www.opengroup.org/onlinepubs/009695399/functions/utime.html, the
> last paragraph of the DESCRIPTION section, where it is spelled out. Please
> note that the Linux man page of utime/utimes does not spell out that
> detail, but Linux implements the POSIX semantics as specified in the given
> link.
>
> Concerning the section "cron.daily drift": SUSE 9.2 and earlier had no
> drift, because it explicitly deleted the timestamp files at a given time
> with own cron jobs. I don't know about SUSE 9.3. I have not observed drift
> on SUSE 10.0, though analysis of the code leads to the suspicion that it
> might happen there. (I have to say that I liked the implementation of 9.2
> better than the one of 10.0.)

I reported the drift as bug to suse including a solution. The solution has
been accepted and after that the daily scripts don't drift anymore...
However, I don't remember the version.

Thanks a lot for your information, it's highly appreciated, it would be great
if add it to the wiki.


--
Richard Bos
Without a home the journey is endless

< Previous Next >
Follow Ups